Re: Support for LC_TIME
El 2014-05-08 13:20, Marc Espie escribió: As for portability issues: programs stay with the C locale *in any case* unless they do setlocale() right at the start, in which case they explicitly say yes, I want to be localized. So, from that point of view the portability issues are minimal (yes, I'm aware of the can of worms that threads+locale may open). xlocale addresses that. That said, I don't have a general problem with adding other locale categories. I believe LC_TIME would provide a useful testbed for eventually switching all our locales to the localedef format (including LC_CTYPE). Alas, the proposed diff does something else, and unfortunately I don't have enough time for a detailed rabbit hole discussion and review with a lot of back-and-forth that we had when discussing similar diffs in the past. THAT on the other hand is the issue at hand... chronic time shortage to be certain that what we do for locales isn't dangerous... I would like a little of clarification about something else that Stefan is talking about. I have been looking for ways to implement whole xlocale and whole LC_* support that is also part of libc specially to support well spanish . The tables with data of collations, formats for numerical and monetary quantities adn time format for different countries that I have been using are from FreeBSD's, since they are BSD licensed, cover a lot of countries and somehow developed. So when I have sent more than is immediatly needed is to make easier future implementation of xlocale or other LC_* or to use FreeBSD tables (or what tables do you recommend me to use? are there tables in localedef format and BSD-license compatible available somewhere?) I have not been adding anything to weak security. I understand any change can lead to security problems and I thank and appreciate the time any developer spends auditing. All the suggestions that Stefan has asked me in past, I have implemented (All what I have sent and the suggestions I have received from Stephan and other developers I have included with credit in adJ: https://github.com/pasosdeJesus/adJ/tree/OBSD_CURRENT/arboldes/usr/src ). The LC_TIME implementation is shorter IMHO than the other LC_* and then faster to audit, so if you want I can try to send very short diffs in separate emails.
Re: Support for LC_TIME
Answering bad question I made (sorry): El 2014-05-12 05:55, vtamara escribió: (or what tables do you recommend me to use? are there tables in localedef format and BSD-license compatible available somewhere?) http://unicode.org/cldr/trac/browser/tags/release-1-9/posix/ However for the moment I don't have the time to implement parser for localedef and use CLDR tables. Hope to find time for that in future (hopefully for 5.7).
Re: amd64 support for AR9485
El 2014-05-09 07:23, Stefan Sperling escribió: Further work is needed. I have diffs which do much more but don't yet work either. I've given up on trying to get this to work for now, and will share my diffs with anyone who wants to take over. If you're an aspiring wifi hacker, then this is for you. If not, just buy a supported card. I cannot tell I can take over, but I have the hardware and would like to try your diffs, learn (a lot I need) and try to adapt from other implementations (not much time now but I would like to see if netbsd or freebsd support it).
Re: Remove p2p loopback hack in nd6_rtrequest()
On 07/05/14(Wed) 12:46, Martin Pieuchot wrote:
Diff below stops abusing nd6_rtrequest() for loopback interfaces, which
means we can remove the special hack below and reduce the differences
with arp_rtrequest().
This diff introduces two changes in the inet6 routing table, but they
should not matter. The first one is that the gateway of the link-local
entry for loopback interfaces is no longer a buggy link-layer address:
-fe80::1%lo0link#6 UHL
00 - 4 lo0
+fe80::1%lo0fe80::1%lo0UHL
00 - 4 lo0
The second one is that every route to network associated to the
loopback interface will now have the mtu of this interface:
-ff02::/16 ::1UGRS
00 - 8 lo0
+ff02::/16 ::1UGRS
00 33192 8 lo0
Both changes are consistent with the IPv4 behavior, ok?
Anyone?
Index: netinet6/in6.c
===
RCS file: /home/ncvs/src/sys/netinet6/in6.c,v
retrieving revision 1.136
diff -u -p -r1.136 in6.c
--- netinet6/in6.c5 May 2014 11:44:33 - 1.136
+++ netinet6/in6.c7 May 2014 10:29:24 -
@@ -1399,7 +1399,7 @@ in6_ifinit(struct ifnet *ifp, struct in6
/* Add ownaddr as loopback rtentry, if necessary (ex. on p2p link). */
if (newhost) {
/* set the rtrequest function to create llinfo */
- if ((ifp-if_flags IFF_POINTOPOINT) == 0)
+ if ((ifp-if_flags (IFF_LOOPBACK | IFF_POINTOPOINT)) == 0)
ia6-ia_ifa.ifa_rtrequest = nd6_rtrequest;
rt_ifa_addloop((ia6-ia_ifa));
Index: netinet6/nd6.c
===
RCS file: /home/ncvs/src/sys/netinet6/nd6.c,v
retrieving revision 1.116
diff -u -p -r1.116 nd6.c
--- netinet6/nd6.c7 May 2014 08:14:59 - 1.116
+++ netinet6/nd6.c7 May 2014 10:29:24 -
@@ -1059,20 +1059,14 @@ nd6_rtrequest(int req, struct rtentry *r
#endif
/* FALLTHROUGH */
case RTM_RESOLVE:
- if ((ifp-if_flags (IFF_POINTOPOINT | IFF_LOOPBACK)) == 0) {
- /*
- * Address resolution isn't necessary for a point to
- * point link, so we can skip this test for a p2p link.
- */
- if (gate-sa_family != AF_LINK ||
- gate-sa_len sizeof(null_sdl)) {
- log(LOG_DEBUG, %s: bad gateway value: %s\n,
- __func__, ifp-if_xname);
- break;
- }
- SDL(gate)-sdl_type = ifp-if_type;
- SDL(gate)-sdl_index = ifp-if_index;
+ if (gate-sa_family != AF_LINK ||
+ gate-sa_len sizeof(null_sdl)) {
+ log(LOG_DEBUG, %s: bad gateway value: %s\n,
+ __func__, ifp-if_xname);
+ break;
}
+ SDL(gate)-sdl_type = ifp-if_type;
+ SDL(gate)-sdl_index = ifp-if_index;
if (ln != NULL)
break; /* This happens on a route change */
/*
Re: Support for LC_TIME
On Mon, May 12, 2014 at 05:55:55AM -0400, vtamara wrote: I would like a little of clarification about something else that Stefan is talking about. In my dream world, I would like a locale implementation that follows the POSIX standard, supports multibyte characters throughout, avoids file formats FreeBSD made up in 1995 (POSIX specifies a file format for localedef that we could use), and uses data provided by unicode.org as much as possible (e.g. it might be possible to derive all our LC_CTYPE data from there in some automated fashion to ease maintenance). All the suggestions that Stefan has asked me in past, I have implemented (All what I have sent and the suggestions I have received from Stephan and other developers I have included with credit in adJ: https://github.com/pasosdeJesus/adJ/tree/OBSD_CURRENT/arboldes/usr/src ). It looks like, at this point in time, and maybe forever, there aren't any developers who are interested in spending their time on driving OpenBSD's locales into the direction you want to go. I spent a lot of time on your LC_COLLATE diffs, and unfortunately it was just you and me without anyone else participating (i.e. there was a general lack of interest, so we were working in a vacuum, which is bad). When I realised your proposed LC_COLLATE changes (ported from FreeBSD's 1995 implementation) couldn't support multibyte outside the latin1 range I gave up because that's too far away from my dream world. At the moment I have several other things I'd like to work on so I'm not going to dive into reviewing your diffs because doing so would take time away from these other things. Note that there is a gsoc student over at FreeBSD who is digging teeth into LC_COLLATE. Perhaps you would have more fun and better results trying to help out there? https://www.google-melange.com/gsoc/project/details/google/gsoc2014/ghostmansd/570483752256?PageSpeed=noscript
Re: amd64 support for AR9485
On Mon, May 12, 2014 at 06:40:22AM -0400, vtamara wrote:
El 2014-05-09 07:23, Stefan Sperling escribió:
Further work is needed.
I have diffs which do much more but don't yet work either.
I've given up on trying to get this to work for now, and will
share my diffs with anyone who wants to take over. If you're
an aspiring wifi hacker, then this is for you. If not, just
buy a supported card.
I cannot tell I can take over, but I have the hardware and would like to try
your diffs, learn (a lot I need) and try to adapt from other implementations
(not much time now but I would like to see if netbsd or freebsd support it).
FreeBSD supports it (ath driver). Linux does, too (ath9k driver).
I've studied their code and tried to make the necessary changes
to ar9003.c in our tree. In my case, the hardware fails to perform
I/Q calibration. If I disable this calibration it gets further but
ends up sending a storm TX/RX error interrupts.
I don't know if the problem in in our existing ar9003.c code, or
in the changes I made while trying to port AR9485 support over.
I haven't looked at this in a while. Last I looked was at b2k13.
This has gotten too large, and my next step would be to get rid
of parts that aren't absolutely necessary for progress.
I believe that ar9003.c has never been working. We don't use it
for any chipset that already works with athn. It is full of untested
code and the problems are hard for me to spot.
Index: ar9003.c
===
RCS file: /cvs/src/sys/dev/ic/ar9003.c,v
retrieving revision 1.27
diff -u -p -r1.27 ar9003.c
--- ar9003.c7 Aug 2013 01:06:28 - 1.27
+++ ar9003.c21 Oct 2013 16:20:04 -
@@ -93,6 +93,7 @@ void ar9003_rx_intr(struct athn_softc *,
intar9003_tx_process(struct athn_softc *);
void ar9003_tx_intr(struct athn_softc *);
intar9003_swba_intr(struct athn_softc *);
+void ar9003_bb_watchdog_intr(struct athn_softc *);
intar9003_intr(struct athn_softc *);
intar9003_tx(struct athn_softc *, struct mbuf *, struct ieee80211_node *,
int);
@@ -119,7 +120,7 @@ voidar9003_do_calib(struct athn_softc *
void ar9003_next_calib(struct athn_softc *);
void ar9003_calib_iq(struct athn_softc *);
intar9003_get_iq_corr(struct athn_softc *, int32_t[], int32_t[]);
-intar9003_calib_tx_iq(struct athn_softc *);
+intar9003_calib_tx_iq_result(struct athn_softc *);
void ar9003_paprd_calib(struct athn_softc *, struct ieee80211_channel *);
intar9003_get_desired_txgain(struct athn_softc *, int, int);
void ar9003_force_txgain(struct athn_softc *, uint32_t);
@@ -147,6 +148,7 @@ voidar9003_disable_ofdm_weak_signal(str
void ar9003_set_cck_weak_signal(struct athn_softc *, int);
void ar9003_set_firstep_level(struct athn_softc *, int);
void ar9003_set_spur_immunity_level(struct athn_softc *, int);
+void ar9003_init_pll(struct athn_softc *);
/* Extern functions. */
void athn_stop(struct ifnet *, int);
@@ -205,6 +207,9 @@ ar9003_attach(struct athn_softc *sc)
sc-obs_off = AR_OBS;
sc-gpio_input_en_off = AR_GPIO_INPUT_EN_VAL;
+ sc-workaround = AR_READ(sc, AR_WA) |
+ AR_WA_ASPM_TIMER_BASED_DISABLE | AR_WA_D3_L1_DISABLE;
+
if (!(sc-flags ATHN_FLAG_PCIE))
athn_config_nonpcie(sc);
else
@@ -563,6 +568,7 @@ ar9003_rfsilent_init(struct athn_softc *
AR_SETBITS(sc, AR_GPIO_INPUT_EN_VAL, AR_GPIO_INPUT_EN_VAL_RFSILENT_BB);
reg = AR_READ(sc, AR_GPIO_INPUT_MUX2);
reg = RW(reg, AR_GPIO_INPUT_MUX2_RFSILENT, 0);
+ reg = RW(reg, AR_GPIO_INPUT_MUX2_RFSILENT, sc-rfsilent_pin);
AR_WRITE(sc, AR_GPIO_INPUT_MUX2, reg);
ar9003_gpio_config_input(sc, sc-rfsilent_pin);
AR_SETBITS(sc, AR_PHY_TEST, AR_PHY_TEST_RFSILENT_BB);
@@ -1310,13 +1316,37 @@ ar9003_swba_intr(struct athn_softc *sc)
}
#endif
+void
+ar9003_bb_watchdog_intr(struct athn_softc *sc)
+{
+ uint32_t status, reg;
+ static int phy_restart_disabled;
+
+ status = AR_READ(sc, AR_PHY_PANIC_WD_STATUS);
+ AR_WRITE(sc, AR_PHY_PANIC_WD_STATUS,
+ status ~AR_PHY_PANIC_WD_STATUS_CLR);
+
+ if (!phy_restart_disabled
+ MS(status, AR_PHY_PANIC_WD_RX_OFDM) == 0xb) {
+ /* BB received unsupported frame rate and will hang
+* if the PHY is restarted. Disable PHY restart. */
+ reg = AR_READ(sc, AR_PHY_RESTART);
+ reg = ~AR_PHY_RESTART_ENA;
+ AR_WRITE(sc, AR_PHY_RESTART, reg);
+ phy_restart_disabled = 1;
+ }
+}
+
int
ar9003_intr(struct athn_softc *sc)
{
uint32_t intr, intr2, intr5, sync;
+ static int count;
/* Get pending interrupts. */
intr = AR_READ(sc, AR_INTR_ASYNC_CAUSE);
+ if (count 4)
+ printf(%s: AR_INTR_ASYNC_CAUSE=0x%x\n, __func__, intr);
if (!(intr AR_INTR_MAC_IRQ) || intr ==
[PATCH 2/2] include openssl/evp.h for OPENSSL_add_all_algorithms_noconf()
From: Brent Cook bust...@gmail.com --- rc4/rc4test.c | 1 + 1 file changed, 1 insertion(+) diff --git a/rc4/rc4test.c b/rc4/rc4test.c index a0b08a6..c4d34b1 100644 --- a/rc4/rc4test.c +++ b/rc4/rc4test.c @@ -60,6 +60,7 @@ #include stdlib.h #include string.h +#include openssl/evp.h #include openssl/rc4.h #include openssl/sha.h -- 1.9.2
[PATCH 0/2] build warning fixes for regress/libcrypto
Hi all, Here are some minor build fixes for the libcrypto regression tests. - Brent
[PATCH 1/2] use correct size_t formatter, include string.h for memcmp
From: Brent Cook bust...@gmail.com
---
base64/base64test.c | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/base64/base64test.c b/base64/base64test.c
index a7d167e..fedbdcd 100644
--- a/base64/base64test.c
+++ b/base64/base64test.c
@@ -19,6 +19,7 @@
#include err.h
#include stdio.h
+#include string.h
#define BUF_SIZE 128
@@ -205,7 +206,7 @@ base64_encoding_test(int test_no, struct base64_test *bt,
int test_nl)
len = BIO_write(bio_mem, bt-in, bt-in_len);
if (len != bt-in_len) {
- fprintf(stderr, FAIL: test %i - only wrote %i out of %i
+ fprintf(stderr, FAIL: test %i - only wrote %i out of %zu
characters\n, test_no, len, bt-in_len);
failure = 1;
goto done;
@@ -296,7 +297,7 @@ base64_decoding_test(int test_no, struct base64_test *bt,
int test_nl)
len = BIO_read(bio_mem, buf, BUF_SIZE);
if (len != bt-valid_len (bt-in_len != 0 || len != -1)) {
fprintf(stderr, FAIL: test %i - decoding resulted in %i
- characters instead of %i\n, test_no, len, bt-valid_len);
+ characters instead of %zu\n, test_no, len, bt-valid_len);
fprintf(stderr, input: );
for (i = 0; i inlen; i++)
fprintf(stderr, %c, input[i]);
--
1.9.2
m-m_pkthdr.rcvif and ip6_input()
Like the previous diffs, it reduces the number of m-m_pkthdr.rcvif
occurrences, this time in ip6_input(). Should be no functional change.
Ok?
Index: netinet6/ip6_input.c
===
RCS file: /home/ncvs/src/sys/netinet6/ip6_input.c,v
retrieving revision 1.124
diff -u -p -r1.124 ip6_input.c
--- netinet6/ip6_input.c14 Apr 2014 09:06:42 - 1.124
+++ netinet6/ip6_input.c12 May 2014 13:08:35 -
@@ -190,6 +190,7 @@ extern struct route_in6 ip6_forward_rt;
void
ip6_input(struct mbuf *m)
{
+ struct ifnet *ifp;
struct ip6_hdr *ip6;
int off, nest;
u_int32_t plen;
@@ -202,9 +203,8 @@ ip6_input(struct mbuf *m)
int srcrt = 0, isanycast = 0;
u_int rtableid = 0;
- /*
-* mbuf statistics by kazu
-*/
+ ifp = m-m_pkthdr.rcvif;
+
if (m-m_flags M_EXT) {
if (m-m_next)
ip6stat.ip6s_mext2m++;
@@ -214,23 +214,21 @@ ip6_input(struct mbuf *m)
if (m-m_next) {
if (m-m_flags M_LOOP) {
ip6stat.ip6s_m2m[lo0ifp-if_index]++; /*XXX*/
- } else if (m-m_pkthdr.rcvif-if_index
nitems(ip6stat.ip6s_m2m))
- ip6stat.ip6s_m2m[m-m_pkthdr.rcvif-if_index]++;
+ } else if (ifp-if_index nitems(ip6stat.ip6s_m2m))
+ ip6stat.ip6s_m2m[ifp-if_index]++;
else
ip6stat.ip6s_m2m[0]++;
} else
ip6stat.ip6s_m1++;
}
- in6_ifstat_inc(m-m_pkthdr.rcvif, ifs6_in_receive);
+ in6_ifstat_inc(ifp, ifs6_in_receive);
ip6stat.ip6s_total++;
if (m-m_len sizeof(struct ip6_hdr)) {
- struct ifnet *inifp;
- inifp = m-m_pkthdr.rcvif;
if ((m = m_pullup(m, sizeof(struct ip6_hdr))) == NULL) {
ip6stat.ip6s_toosmall++;
- in6_ifstat_inc(inifp, ifs6_in_hdrerr);
+ in6_ifstat_inc(ifp, ifs6_in_hdrerr);
return;
}
}
@@ -239,13 +237,12 @@ ip6_input(struct mbuf *m)
if ((ip6-ip6_vfc IPV6_VERSION_MASK) != IPV6_VERSION) {
ip6stat.ip6s_badvers++;
- in6_ifstat_inc(m-m_pkthdr.rcvif, ifs6_in_hdrerr);
+ in6_ifstat_inc(ifp, ifs6_in_hdrerr);
goto bad;
}
#if NCARP 0
- if (m-m_pkthdr.rcvif-if_type == IFT_CARP
- ip6-ip6_nxt != IPPROTO_ICMPV6
+ if (ifp-if_type == IFT_CARP ip6-ip6_nxt != IPPROTO_ICMPV6
carp_lsdrop(m, AF_INET6, ip6-ip6_src.s6_addr32,
ip6-ip6_dst.s6_addr32))
goto bad;
@@ -261,14 +258,14 @@ ip6_input(struct mbuf *m)
* XXX: badscope is not very suitable for a multicast source.
*/
ip6stat.ip6s_badscope++;
- in6_ifstat_inc(m-m_pkthdr.rcvif, ifs6_in_addrerr);
+ in6_ifstat_inc(ifp, ifs6_in_addrerr);
goto bad;
}
if ((IN6_IS_ADDR_LOOPBACK(ip6-ip6_src) ||
IN6_IS_ADDR_LOOPBACK(ip6-ip6_dst))
- (m-m_pkthdr.rcvif-if_flags IFF_LOOPBACK) == 0) {
+ (ifp-if_flags IFF_LOOPBACK) == 0) {
ip6stat.ip6s_badscope++;
- in6_ifstat_inc(m-m_pkthdr.rcvif, ifs6_in_addrerr);
+ in6_ifstat_inc(ifp, ifs6_in_addrerr);
goto bad;
}
if (IN6_IS_ADDR_MC_INTFACELOCAL(ip6-ip6_dst)
@@ -280,7 +277,7 @@ ip6_input(struct mbuf *m)
* as the outgoing/incoming interface.
*/
ip6stat.ip6s_badscope++;
- in6_ifstat_inc(m-m_pkthdr.rcvif, ifs6_in_addrerr);
+ in6_ifstat_inc(ifp, ifs6_in_addrerr);
goto bad;
}
@@ -299,7 +296,7 @@ ip6_input(struct mbuf *m)
if (IN6_IS_ADDR_V4MAPPED(ip6-ip6_src) ||
IN6_IS_ADDR_V4MAPPED(ip6-ip6_dst)) {
ip6stat.ip6s_badscope++;
- in6_ifstat_inc(m-m_pkthdr.rcvif, ifs6_in_addrerr);
+ in6_ifstat_inc(ifp, ifs6_in_addrerr);
goto bad;
}
#if 0
@@ -313,7 +310,7 @@ ip6_input(struct mbuf *m)
if (IN6_IS_ADDR_V4COMPAT(ip6-ip6_src) ||
IN6_IS_ADDR_V4COMPAT(ip6-ip6_dst)) {
ip6stat.ip6s_badscope++;
- in6_ifstat_inc(m-m_pkthdr.rcvif, ifs6_in_addrerr);
+ in6_ifstat_inc(ifp, ifs6_in_addrerr);
goto bad;
}
#endif
@@ -323,7 +320,7 @@ ip6_input(struct mbuf *m)
* Packet filter
*/
odst = ip6-ip6_dst;
- if (pf_test(AF_INET6, PF_IN, m-m_pkthdr.rcvif, m, NULL) != PF_PASS)
+ if (pf_test(AF_INET6, PF_IN, ifp, m, NULL) != PF_PASS)
goto bad;
if (m == NULL)
Re: m-m_pkthdr.rcvif and ip6_input()
On 12 May 2014 15:12, Martin Pieuchot mpieuc...@nolizard.org wrote: Like the previous diffs, it reduces the number of m-m_pkthdr.rcvif occurrences, this time in ip6_input(). Should be no functional change. Ok? OK
Re: dhclient bug when joining new wireless lan
Sorry, I'm running with some custom changes to make some other hardware work on this box, and at the moment I haven't had time to update them for -current. Mmm what hardware? It may be that it's supported in -current already and I'm running with some changes to wscons to support my 122-key mainframe style keyboard in a useful way. That is to say supporting VT switching and other 'commands' on dedicated keys. Also, my repeat key patch from last year never made it in to mainline to I've got that here as well. Around November last year, the framebuffer code was changed which made the console impossibly slow for me on three boxes, so I've made some local changes to repair that regression. Also, regarding wifi, I am experimenting with three wifi cards, one of which gained support in mainline between 5.4-release and 5.5-release, onr of the others is long supported, the other not supported or working very well at all at the moment, despite being almost identical to another that I have. When using OpenBSD with a wifi card in host AP mode, it's obvious that something is wrong with the rate control code, because it never seems to go about 2 mbit. So, I've got some changes to the rate control code and one device driver in at the same time. With all this going on, it's not trivial to follow -current on these boxes at the moment. But I will see what I can do and maybe port some of my bits forward. It's really a shame that the repeat key and other wscons changes are not of interest, because I'm sure there are other people that could use them. Unfortunately after my modified repeat key patch was rejected, (silently), I reverted to a simpler version that breaks other stuff, because it suited me better for my own boxes and was easier to port forward every six months. Oh, and I fixed a couple of time related bugs in my tree as well. anyway for getting support inside OpenBSD for that hardware patch will need to be done against -current. Not much point if nodbody's interested in it apart from me:-). Look back in the archives... This was posted around the 5.0 era: http://marc.info/?l=openbsd-bugsamp;m=132851264207109amp;w=2 -- Creamy! 3
