Re: libcrypto functionality in 7.0 won't work in 7.1.
On Thu, Apr 21, 2022 at 10:53:29PM -0500, Luke Small wrote: > I redownloaded /usr/src. > I made sample code using libcrypto. I won't even compile now. > > Is this some way to prevent user programs from digging into the internal > structures? EVP_CIPHER_CTX is a private struct (programs using it should only manipulate the pointer). so yes, internal structures are for internal usage only. > I want to reuse the working “iv” for further transactions. Is that not > going to be possible? You should use the public interface for that: EVP_CIPHER_CTX_get_iv() in your case. see the whole man page (man EVP_CIPHER_CTX_get_iv) to get the public interface. -- Sebastien Marie
Re: libcrypto functionality in 7.0 won't work in 7.1.
It fails on the memcpy(). On Thu, Apr 21, 2022 at 10:53 PM Luke Small wrote: > I redownloaded /usr/src. > I made sample code using libcrypto. I won't even compile now. > > Is this some way to prevent user programs from digging into the internal > structures? > > I want to reuse the working “iv” for further transactions. Is that not > going to be possible? > > If you finish a transmission and start again, will you be able to reuse > the working iv, or will it default to the original? > > -Luke > -- > -Luke >
libcrypto functionality in 7.0 won't work in 7.1.
I redownloaded /usr/src.
I made sample code using libcrypto. I won't even compile now.
Is this some way to prevent user programs from digging into the internal
structures?
I want to reuse the working “iv” for further transactions. Is that not
going to be possible?
If you finish a transmission and start again, will you be able to reuse the
working iv, or will it default to the original?
-Luke
--
-Luke
/*
struct evp_cipher_ctx_st {
const EVP_CIPHER *cipher;
ENGINE *engine;
int encrypt;
int buf_len;
unsigned char oiv[EVP_MAX_IV_LENGTH]; // original iv
unsigned char iv[EVP_MAX_IV_LENGTH]; // working iv
unsigned char buf[EVP_MAX_BLOCK_LENGTH];
int num;
void *app_data;
int key_len;
unsigned long flags;
void *cipher_data;
int final_used;
int block_mask;
unsigned char final[EVP_MAX_BLOCK_LENGTH];
}; // EVP_CIPHER_CTX
*/
#include
#include
#include
/* KEYSIZE# can be 16(128 bits), 24(192 bits), or 32(256 bits) */
#define KEYSIZE 32
#define IVSIZE 12
#define AADSIZE 32
#define AESGCMTAGLEN 16
int main()
{
u_char key[KEYSIZE];
u_char ivec[IVSIZE];
int inlen = 20;
u_char inbuf[20];
u_char aad[AADSIZE];
u_char outbuf[100];
arc4random_buf(key, KEYSIZE);
arc4random_buf(ivec, IVSIZE);
arc4random_buf(inbuf, 20);
arc4random_buf(aad, AADSIZE);
EVP_CIPHER_CTX *CTX = NULL;
int tmplen = 0, outlen = 0;
CTX = EVP_CIPHER_CTX_new();
if (CTX == NULL)
errx(1, "cannot make new cipher context");
if (!EVP_EncryptInit_ex(CTX, EVP_aes_256_gcm(), NULL, NULL, NULL))
err(1, "encrypt set EVP_aes_256_gcm failed");
if (!EVP_CIPHER_CTX_ctrl(CTX, EVP_CTRL_GCM_SET_IVLEN, IVSIZE, NULL))
err(1, "encrypt set ivsize failed");
if (!EVP_EncryptInit_ex(CTX, NULL, NULL, key, ivec))
err(1, "encrypt set key and ivec");
if (EVP_EncryptUpdate(CTX, NULL, , aad, AADSIZE) != 1)
err(1, "encrypt set aad");
if (!EVP_EncryptUpdate(CTX, outbuf, , inbuf, inlen))
{
EVP_CIPHER_CTX_free(CTX);
err(1, "EncryptUpdate1 failed.");
}
if (!EVP_EncryptFinal_ex(CTX, outbuf + outlen, ))
{
EVP_CIPHER_CTX_free(CTX);
err(1, "EncryptFinal failed.");
}
outlen += tmplen;
if (!EVP_CIPHER_CTX_ctrl(CTX, EVP_CTRL_GCM_GET_TAG, AESGCMTAGLEN, outbuf + outlen))
{
EVP_CIPHER_CTX_free(CTX);
err(1, "EVP_CTRL_GCM_GET_TAG failed.");
}
memcpy(ivec, CTX->iv, IVSIZE);
EVP_CIPHER_CTX_free(CTX);
return outlen + AESGCMTAGLEN;
}
Re: Ralink RT2790 - connection problems
On Thu, Apr 21, 2022 at 10:34:22PM +0200, Stefan Sperling wrote:
> On Thu, Apr 21, 2022 at 10:31:46PM +0200, Stefan Sperling wrote:
> > On Thu, Apr 21, 2022 at 09:15:57PM +0200, Stefan Sperling wrote:
> > > On Thu, Apr 21, 2022 at 08:58:48PM +0200, Sven Wolf wrote:
> > > > But when I build a new kernel with the sources from 2022-03-15
> > > > everything is
> > > > fine.
> > > >
> > > > Maybe this commit causes this behaviour/bug
> > > > https://marc.info/?l=openbsd-cvs=16472610775=2
> > >
> > > Looks like a bug in ral(4) (uninitialized variable) which has been
> > > exposed by the above commit. Does the patch below help?
> > >
> > > If it does then I will do a sweep of all wifi drivers for similar
> > > problems.
> > > Sorry for not catching this earlier. This could have been caught had it
> > > occurred to me to check for any uninitialized use of this struct when
> > > I added a new field...
> >
> > I did take a look already just in case, and it's not looking good...
> > This fixes the places I've found so far:
>
> Sorry, the previous diff missed the ral(4) fix I sent earlier.
> A better version of this fix is included here (thanks to miod for off-list
> feedback).
I applied the if_urtwn.c change and it seemed to help my urtwn(4) get a lease
much faster.
So ok krw@ fwiw.
Ken
>
> diff b3dff8d102fea35ec827f7e82565722dc4185589
> d5aaa0e75d191916f6c8da91b842079511d38fd3
> blob - 9c70f4dc5e96467bb4100e022ba59e918797e85f
> blob + c0c96f2f5614858df29f49680d8349832af8d55a
> --- sys/dev/ic/acx.c
> +++ sys/dev/ic/acx.c
> @@ -1354,7 +1354,7 @@ acx_rxeof(struct acx_softc *sc)
> sc->chip_rxbuf_exhdr);
> wh = mtod(m, struct ieee80211_frame *);
>
> - rxi.rxi_flags = 0;
> + memset(, 0, sizeof(rxi));
> if ((wh->i_fc[1] & IEEE80211_FC1_WEP) &&
> sc->chip_hw_crypt) {
> /* Short circuit software WEP */
> blob - 6208492c94c2af3d15e158e8329f881565efd232
> blob + 28db8e32130a83eeb9e057cfaed6eb9d8d625428
> --- sys/dev/ic/an.c
> +++ sys/dev/ic/an.c
> @@ -462,7 +462,7 @@ an_rxeof(struct an_softc *sc)
> #endif /* NBPFILTER > 0 */
>
> wh = mtod(m, struct ieee80211_frame *);
> - rxi.rxi_flags = 0;
> + memset(, 0, sizeof(rxi));
> if (wh->i_fc[1] & IEEE80211_FC1_WEP) {
> /*
>* WEP is decrypted by hardware. Clear WEP bit
> blob - e9ff551127c7e937b52f99577ade8bc5dde91763
> blob + aafd14161600420dfd90ff3f2ecc093e11f5c33f
> --- sys/dev/ic/ar5008.c
> +++ sys/dev/ic/ar5008.c
> @@ -1039,7 +1039,7 @@ ar5008_rx_process(struct athn_softc *sc, struct mbuf_l
> m_adj(m, -IEEE80211_CRC_LEN);
>
> /* Send the frame to the 802.11 layer. */
> - rxi.rxi_flags = 0; /* XXX */
> + memset(, 0, sizeof(rxi));
> rxi.rxi_rssi = MS(ds->ds_status4, AR_RXS4_RSSI_COMBINED);
> rxi.rxi_rssi += AR_DEFAULT_NOISE_FLOOR;
> rxi.rxi_tstamp = ds->ds_status2;
> blob - 5aa99be1508ee4b893a50adf89f8c83eaad9e94b
> blob + e45a4441a62255fb4ef4a386112a477a2f5b58ed
> --- sys/dev/ic/ar9003.c
> +++ sys/dev/ic/ar9003.c
> @@ -1026,7 +1026,7 @@ ar9003_rx_process(struct athn_softc *sc, int qid, stru
> m_adj(m, -IEEE80211_CRC_LEN);
>
> /* Send the frame to the 802.11 layer. */
> - rxi.rxi_flags = 0; /* XXX */
> + memset(, 0, sizeof(rxi));
> rxi.rxi_rssi = MS(ds->ds_status5, AR_RXS5_RSSI_COMBINED);
> rxi.rxi_tstamp = ds->ds_status3;
> ieee80211_inputm(ifp, m, ni, , ml);
> blob - 9a640630ecdd5e55125bae10cbd31665bf7ce9e6
> blob + a43ad3f9706addf3886a8ce74c63adb50c58589a
> --- sys/dev/ic/ath.c
> +++ sys/dev/ic/ath.c
> @@ -1936,7 +1936,7 @@ ath_rx_proc(void *arg, int npending)
> #endif
> m_adj(m, -IEEE80211_CRC_LEN);
> wh = mtod(m, struct ieee80211_frame *);
> - rxi.rxi_flags = 0;
> + memset(, 0, sizeof(rxi));
> if (!ath_softcrypto && (wh->i_fc[1] & IEEE80211_FC1_WEP)) {
> /*
>* WEP is decrypted by hardware. Clear WEP bit
> blob - 49b4089c69fe17b0215d514d0b3b1215a87b69b8
> blob + 04b4f0d393e7eb142d707c76090668df556bf845
> --- sys/dev/ic/atw.c
> +++ sys/dev/ic/atw.c
> @@ -3175,7 +3175,7 @@ atw_rxintr(struct atw_softc *sc)
>
> wh = mtod(m, struct ieee80211_frame *);
> ni = ieee80211_find_rxnode(ic, wh);
> - rxi.rxi_flags = 0;
> + memset(, 0, sizeof(rxi));
> #if 0
> if (atw_hw_decrypted(sc, wh)) {
> wh->i_fc[1] &= ~IEEE80211_FC1_WEP;
> @@ -3183,7 +3183,6 @@ atw_rxintr(struct atw_softc *sc)
> }
> #endif
> rxi.rxi_rssi = (int)rssi;
> - rxi.rxi_tstamp = 0;
> ieee80211_inputm(ifp, m, ni, , );
> /*
>* The frame may have caused the node to be marked for
> blob -
Re: Ralink RT2790 - connection problems
On Thu, Apr 21, 2022 at 10:31:46PM +0200, Stefan Sperling wrote:
> On Thu, Apr 21, 2022 at 09:15:57PM +0200, Stefan Sperling wrote:
> > On Thu, Apr 21, 2022 at 08:58:48PM +0200, Sven Wolf wrote:
> > > But when I build a new kernel with the sources from 2022-03-15 everything
> > > is
> > > fine.
> > >
> > > Maybe this commit causes this behaviour/bug
> > > https://marc.info/?l=openbsd-cvs=16472610775=2
> >
> > Looks like a bug in ral(4) (uninitialized variable) which has been
> > exposed by the above commit. Does the patch below help?
> >
> > If it does then I will do a sweep of all wifi drivers for similar problems.
> > Sorry for not catching this earlier. This could have been caught had it
> > occurred to me to check for any uninitialized use of this struct when
> > I added a new field...
>
> I did take a look already just in case, and it's not looking good...
> This fixes the places I've found so far:
Sorry, the previous diff missed the ral(4) fix I sent earlier.
A better version of this fix is included here (thanks to miod for off-list
feedback).
diff b3dff8d102fea35ec827f7e82565722dc4185589
d5aaa0e75d191916f6c8da91b842079511d38fd3
blob - 9c70f4dc5e96467bb4100e022ba59e918797e85f
blob + c0c96f2f5614858df29f49680d8349832af8d55a
--- sys/dev/ic/acx.c
+++ sys/dev/ic/acx.c
@@ -1354,7 +1354,7 @@ acx_rxeof(struct acx_softc *sc)
sc->chip_rxbuf_exhdr);
wh = mtod(m, struct ieee80211_frame *);
- rxi.rxi_flags = 0;
+ memset(, 0, sizeof(rxi));
if ((wh->i_fc[1] & IEEE80211_FC1_WEP) &&
sc->chip_hw_crypt) {
/* Short circuit software WEP */
blob - 6208492c94c2af3d15e158e8329f881565efd232
blob + 28db8e32130a83eeb9e057cfaed6eb9d8d625428
--- sys/dev/ic/an.c
+++ sys/dev/ic/an.c
@@ -462,7 +462,7 @@ an_rxeof(struct an_softc *sc)
#endif /* NBPFILTER > 0 */
wh = mtod(m, struct ieee80211_frame *);
- rxi.rxi_flags = 0;
+ memset(, 0, sizeof(rxi));
if (wh->i_fc[1] & IEEE80211_FC1_WEP) {
/*
* WEP is decrypted by hardware. Clear WEP bit
blob - e9ff551127c7e937b52f99577ade8bc5dde91763
blob + aafd14161600420dfd90ff3f2ecc093e11f5c33f
--- sys/dev/ic/ar5008.c
+++ sys/dev/ic/ar5008.c
@@ -1039,7 +1039,7 @@ ar5008_rx_process(struct athn_softc *sc, struct mbuf_l
m_adj(m, -IEEE80211_CRC_LEN);
/* Send the frame to the 802.11 layer. */
- rxi.rxi_flags = 0; /* XXX */
+ memset(, 0, sizeof(rxi));
rxi.rxi_rssi = MS(ds->ds_status4, AR_RXS4_RSSI_COMBINED);
rxi.rxi_rssi += AR_DEFAULT_NOISE_FLOOR;
rxi.rxi_tstamp = ds->ds_status2;
blob - 5aa99be1508ee4b893a50adf89f8c83eaad9e94b
blob + e45a4441a62255fb4ef4a386112a477a2f5b58ed
--- sys/dev/ic/ar9003.c
+++ sys/dev/ic/ar9003.c
@@ -1026,7 +1026,7 @@ ar9003_rx_process(struct athn_softc *sc, int qid, stru
m_adj(m, -IEEE80211_CRC_LEN);
/* Send the frame to the 802.11 layer. */
- rxi.rxi_flags = 0; /* XXX */
+ memset(, 0, sizeof(rxi));
rxi.rxi_rssi = MS(ds->ds_status5, AR_RXS5_RSSI_COMBINED);
rxi.rxi_tstamp = ds->ds_status3;
ieee80211_inputm(ifp, m, ni, , ml);
blob - 9a640630ecdd5e55125bae10cbd31665bf7ce9e6
blob + a43ad3f9706addf3886a8ce74c63adb50c58589a
--- sys/dev/ic/ath.c
+++ sys/dev/ic/ath.c
@@ -1936,7 +1936,7 @@ ath_rx_proc(void *arg, int npending)
#endif
m_adj(m, -IEEE80211_CRC_LEN);
wh = mtod(m, struct ieee80211_frame *);
- rxi.rxi_flags = 0;
+ memset(, 0, sizeof(rxi));
if (!ath_softcrypto && (wh->i_fc[1] & IEEE80211_FC1_WEP)) {
/*
* WEP is decrypted by hardware. Clear WEP bit
blob - 49b4089c69fe17b0215d514d0b3b1215a87b69b8
blob + 04b4f0d393e7eb142d707c76090668df556bf845
--- sys/dev/ic/atw.c
+++ sys/dev/ic/atw.c
@@ -3175,7 +3175,7 @@ atw_rxintr(struct atw_softc *sc)
wh = mtod(m, struct ieee80211_frame *);
ni = ieee80211_find_rxnode(ic, wh);
- rxi.rxi_flags = 0;
+ memset(, 0, sizeof(rxi));
#if 0
if (atw_hw_decrypted(sc, wh)) {
wh->i_fc[1] &= ~IEEE80211_FC1_WEP;
@@ -3183,7 +3183,6 @@ atw_rxintr(struct atw_softc *sc)
}
#endif
rxi.rxi_rssi = (int)rssi;
- rxi.rxi_tstamp = 0;
ieee80211_inputm(ifp, m, ni, , );
/*
* The frame may have caused the node to be marked for
blob - c245bcdac6953e6e88059fb1fccdc319b412ccfa
blob + d4db3d9384097401f7b48072949c432ead0a4ceb
--- sys/dev/ic/bwfm.c
+++ sys/dev/ic/bwfm.c
@@ -2439,9 +2439,7 @@ bwfm_rx_auth_ind(struct bwfm_softc *sc, struct bwfm_ev
/* Finalize mbuf. */
m->m_pkthdr.len = m->m_len = pktlen;
- rxi.rxi_flags = 0;
- rxi.rxi_rssi = 0;
-
Re: Ralink RT2790 - connection problems
On Thu, Apr 21, 2022 at 09:15:57PM +0200, Stefan Sperling wrote:
> On Thu, Apr 21, 2022 at 08:58:48PM +0200, Sven Wolf wrote:
> > But when I build a new kernel with the sources from 2022-03-15 everything is
> > fine.
> >
> > Maybe this commit causes this behaviour/bug
> > https://marc.info/?l=openbsd-cvs=16472610775=2
>
> Looks like a bug in ral(4) (uninitialized variable) which has been
> exposed by the above commit. Does the patch below help?
>
> If it does then I will do a sweep of all wifi drivers for similar problems.
> Sorry for not catching this earlier. This could have been caught had it
> occurred to me to check for any uninitialized use of this struct when
> I added a new field...
I did take a look already just in case, and it's not looking good...
This fixes the places I've found so far:
diff 78339108684c9eff64beceb07db3a4411c4e9aee /usr/src
blob - 9c70f4dc5e96467bb4100e022ba59e918797e85f
file + sys/dev/ic/acx.c
--- sys/dev/ic/acx.c
+++ sys/dev/ic/acx.c
@@ -1354,7 +1354,7 @@ acx_rxeof(struct acx_softc *sc)
sc->chip_rxbuf_exhdr);
wh = mtod(m, struct ieee80211_frame *);
- rxi.rxi_flags = 0;
+ memset(, 0, sizeof(rxi));
if ((wh->i_fc[1] & IEEE80211_FC1_WEP) &&
sc->chip_hw_crypt) {
/* Short circuit software WEP */
blob - 6208492c94c2af3d15e158e8329f881565efd232
file + sys/dev/ic/an.c
--- sys/dev/ic/an.c
+++ sys/dev/ic/an.c
@@ -462,7 +462,7 @@ an_rxeof(struct an_softc *sc)
#endif /* NBPFILTER > 0 */
wh = mtod(m, struct ieee80211_frame *);
- rxi.rxi_flags = 0;
+ memset(, 0, sizeof(rxi));
if (wh->i_fc[1] & IEEE80211_FC1_WEP) {
/*
* WEP is decrypted by hardware. Clear WEP bit
blob - e9ff551127c7e937b52f99577ade8bc5dde91763
file + sys/dev/ic/ar5008.c
--- sys/dev/ic/ar5008.c
+++ sys/dev/ic/ar5008.c
@@ -1039,7 +1039,7 @@ ar5008_rx_process(struct athn_softc *sc, struct mbuf_l
m_adj(m, -IEEE80211_CRC_LEN);
/* Send the frame to the 802.11 layer. */
- rxi.rxi_flags = 0; /* XXX */
+ memset(, 0, sizeof(rxi));
rxi.rxi_rssi = MS(ds->ds_status4, AR_RXS4_RSSI_COMBINED);
rxi.rxi_rssi += AR_DEFAULT_NOISE_FLOOR;
rxi.rxi_tstamp = ds->ds_status2;
blob - 5aa99be1508ee4b893a50adf89f8c83eaad9e94b
file + sys/dev/ic/ar9003.c
--- sys/dev/ic/ar9003.c
+++ sys/dev/ic/ar9003.c
@@ -1026,7 +1026,7 @@ ar9003_rx_process(struct athn_softc *sc, int qid, stru
m_adj(m, -IEEE80211_CRC_LEN);
/* Send the frame to the 802.11 layer. */
- rxi.rxi_flags = 0; /* XXX */
+ memset(, 0, sizeof(rxi));
rxi.rxi_rssi = MS(ds->ds_status5, AR_RXS5_RSSI_COMBINED);
rxi.rxi_tstamp = ds->ds_status3;
ieee80211_inputm(ifp, m, ni, , ml);
blob - 9a640630ecdd5e55125bae10cbd31665bf7ce9e6
file + sys/dev/ic/ath.c
--- sys/dev/ic/ath.c
+++ sys/dev/ic/ath.c
@@ -1936,7 +1936,7 @@ ath_rx_proc(void *arg, int npending)
#endif
m_adj(m, -IEEE80211_CRC_LEN);
wh = mtod(m, struct ieee80211_frame *);
- rxi.rxi_flags = 0;
+ memset(, 0, sizeof(rxi));
if (!ath_softcrypto && (wh->i_fc[1] & IEEE80211_FC1_WEP)) {
/*
* WEP is decrypted by hardware. Clear WEP bit
blob - 49b4089c69fe17b0215d514d0b3b1215a87b69b8
file + sys/dev/ic/atw.c
--- sys/dev/ic/atw.c
+++ sys/dev/ic/atw.c
@@ -3175,7 +3175,7 @@ atw_rxintr(struct atw_softc *sc)
wh = mtod(m, struct ieee80211_frame *);
ni = ieee80211_find_rxnode(ic, wh);
- rxi.rxi_flags = 0;
+ memset(, 0, sizeof(rxi));
#if 0
if (atw_hw_decrypted(sc, wh)) {
wh->i_fc[1] &= ~IEEE80211_FC1_WEP;
@@ -3183,7 +3183,6 @@ atw_rxintr(struct atw_softc *sc)
}
#endif
rxi.rxi_rssi = (int)rssi;
- rxi.rxi_tstamp = 0;
ieee80211_inputm(ifp, m, ni, , );
/*
* The frame may have caused the node to be marked for
blob - c245bcdac6953e6e88059fb1fccdc319b412ccfa
file + sys/dev/ic/bwfm.c
--- sys/dev/ic/bwfm.c
+++ sys/dev/ic/bwfm.c
@@ -2439,9 +2439,7 @@ bwfm_rx_auth_ind(struct bwfm_softc *sc, struct bwfm_ev
/* Finalize mbuf. */
m->m_pkthdr.len = m->m_len = pktlen;
- rxi.rxi_flags = 0;
- rxi.rxi_rssi = 0;
- rxi.rxi_tstamp = 0;
+ memset(, 0, sizeof(rxi));
ieee80211_input(ifp, m, ic->ic_bss, );
}
@@ -2495,9 +2493,7 @@ bwfm_rx_assoc_ind(struct bwfm_softc *sc, struct bwfm_e
m_freem(m);
return;
}
- rxi.rxi_flags = 0;
- rxi.rxi_rssi = 0;
- rxi.rxi_tstamp = 0;
+ memset(, 0, sizeof(rxi));
ieee80211_input(ifp, m, ni, );
}
@@ -2550,9 +2546,7 @@ bwfm_rx_leave_ind(struct bwfm_softc *sc,
Re: Ralink RT2790 - connection problems
On Thu, Apr 21, 2022 at 08:58:48PM +0200, Sven Wolf wrote:
> But when I build a new kernel with the sources from 2022-03-15 everything is
> fine.
>
> Maybe this commit causes this behaviour/bug
> https://marc.info/?l=openbsd-cvs=16472610775=2
Looks like a bug in ral(4) (uninitialized variable) which has been
exposed by the above commit. Does the patch below help?
If it does then I will do a sweep of all wifi drivers for similar problems.
Sorry for not catching this earlier. This could have been caught had it
occurred to me to check for any uninitialized use of this struct when
I added a new field...
diff a26af1db5d30d7a58f91742886569d0d8891b827 /usr/src
blob - 3178226c0b633534b065088e426e80b5a26853c9
file + sys/dev/ic/rt2860.c
--- sys/dev/ic/rt2860.c
+++ sys/dev/ic/rt2860.c
@@ -1275,6 +1275,8 @@ rt2860_rx_intr(struct rt2860_softc *sc)
uint16_t phy;
#endif
+ memset(, 0, sizeof(rxi));
+
hw = RAL_READ(sc, RT2860_FS_DRX_IDX) & 0xfff;
while (sc->rxq.cur != hw) {
struct rt2860_rx_data *data = >rxq.data[sc->rxq.cur];
Ralink RT2790 - connection problems
Hi list,
on my old Asus eeepc 1000h I have wireless connection problems.
When I use an i386 snapshot > 2022-03-15, then in debug mode I get only
a few networks listed. My network is missing and gets not connected.
ral0: - 2c:91:ab:xx:x:xx6 +66 54M ess privacy! no ""!
ral0: - cc:ce:1e:xx:xx:xx 13 +32 54M ess privacy! no ""!
ral0: SCAN -> SCAN
...
ral0: SCAN -> SCAN
ral0: end passive scan
First I thought that this commit could be the cause:
https://marc.info/?l=openbsd-cvs=164702163820785=2
But when I build a new kernel with the sources from 2022-03-15
everything is fine.
Maybe this commit causes this behaviour/bug
https://marc.info/?l=openbsd-cvs=16472610775=2
The connection problems occur only on the Ralink device.
On a T43 with an Intel 2200bg everything is fine with an current i386
snapshot.
dmesg:
OpenBSD 7.1 (GENERIC.MP) #168: Fri Apr 8 11:48:35 MDT 2022
dera...@i386.openbsd.org:/usr/src/sys/arch/i386/compile/GENERIC.MP
real mem = 2138193920 (2039MB)
avail mem = 2082377728 (1985MB)
random: good seed from bootblocks
mpath0 at root
scsibus0 at mpath0: 256 targets
mainbus0 at root
bios0 at mainbus0: date 10/21/09, BIOS32 rev. 0 @ 0xf0010, SMBIOS rev.
2.5 @ 0xf0720 (30 entries)
bios0: vendor American Megatrends Inc. version "2204" date 10/21/2009
bios0: ASUSTeK Computer INC. 1000H
acpi0 at bios0: ACPI 2.0
acpi0: sleep states S0 S3 S4 S5
acpi0: tables DSDT FACP SLIC APIC MCFG OEMB HPET SSDT
acpi0: wakeup devices P0P2(S4) P0P1(S4) HDAC(S4) P0P4(S4) P0P8(S4)
P0P5(S4) P0P7(S4) P0P9(S4) P0P6(S4)
acpitimer0 at acpi0: 3579545 Hz, 24 bits
acpimadt0 at acpi0 addr 0xfee0: PC-AT compat
cpu0 at mainbus0: apid 0 (boot processor)
cpu0: Intel(R) Atom(TM) CPU N270 @ 1.60GHz ("GenuineIntel" 686-class)
1.60 GHz, 06-1c-02
cpu0:
FPU,V86,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,DTES64,MWAIT,DS-CPL,EST,TM2,SSSE3,xTPR,PDCM,MOVBE,NXE,LAHF,PERF,MELTDOWN
mtrr: Pentium Pro MTRR support, 8 var ranges, 88 fixed ranges
cpu0: apic clock running at 132MHz
cpu1 at mainbus0: apid 1 (application processor)
cpu1: Intel(R) Atom(TM) CPU N270 @ 1.60GHz ("GenuineIntel" 686-class)
1.60 GHz, 06-1c-02
cpu1:
FPU,V86,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,DTES64,MWAIT,DS-CPL,EST,TM2,SSSE3,xTPR,PDCM,MOVBE,NXE,LAHF,PERF,MELTDOWN
ioapic0 at mainbus0: apid 2 pa 0xfec0, version 20, 24 pins, remapped
acpimcfg0 at acpi0
acpimcfg0: addr 0xe000, bus 0-63
acpihpet0 at acpi0: 14318179 Hz
acpiprt0 at acpi0: bus 0 (PCI0)
acpiprt1 at acpi0: bus 3 (P0P5)
acpiprt2 at acpi0: bus 1 (P0P7)
acpiprt3 at acpi0: bus -1 (P0P6)
acpiec0 at acpi0
"PNP0A08" at acpi0 not configured
acpicmos0 at acpi0
"SYN0A04" at acpi0 not configured
acpibat0 at acpi0: BAT0 not present
acpiac0 at acpi0: AC unit online
acpibtn0 at acpi0: LID_
acpibtn1 at acpi0: SLPB
acpibtn2 at acpi0: PWRB
"PNP0C14" at acpi0 not configured
acpicpu0 at acpi0: C1(@1 halt!), PSS
acpicpu1 at acpi0: C1(@1 halt!), PSS
acpitz0 at acpi0: critical temperature is 85 degC
acpivideo0 at acpi0: VGA_
acpivout0 at acpivideo0: LCDD
bios0: ROM list: 0xc/0xec00!
cpu0: Enhanced SpeedStep 1596 MHz: speeds: 1600, 1333, 1067, 800 MHz
pci0 at mainbus0 bus 0: configuration mode 1 (bios)
pchb0 at pci0 dev 0 function 0 "Intel 82945GME Host" rev 0x03
inteldrm0 at pci0 dev 2 function 0 "Intel 82945GME Video" rev 0x03
drm0 at inteldrm0
intagp0 at inteldrm0
agp0 at intagp0: aperture at 0xd000, size 0x1000
inteldrm0: apic 2 int 16, I945GM, gen 3
"Intel 82945GM Video" rev 0x03 at pci0 dev 2 function 1 not configured
azalia0 at pci0 dev 27 function 0 "Intel 82801GB HD Audio" rev 0x02: msi
azalia0: codecs: Realtek ALC269
audio0 at azalia0
ppb0 at pci0 dev 28 function 0 "Intel 82801GB PCIE" rev 0x02: apic 2 int 16
pci1 at ppb0 bus 4
ppb1 at pci0 dev 28 function 1 "Intel 82801GB PCIE" rev 0x02: apic 2 int 17
pci2 at ppb1 bus 3
ale0 at pci2 dev 0 function 0 "Attansic Technology L1E" rev 0xb0:
AR8113, msi, address 00:22:15:xx:xx:xx
atphy0 at ale0 phy 0: F1 10/100/1000 PHY, rev. 9
ppb2 at pci0 dev 28 function 3 "Intel 82801GB PCIE" rev 0x02: apic 2 int 19
pci3 at ppb2 bus 1
ral0 at pci3 dev 0 function 0 "Ralink RT2790" rev 0x00: apic 2 int 19,
address 00:22:43:xx:xx:xx
ral0: MAC/BBP RT2872 (rev 0x0200), RF RT2720 (MIMO 1T2R)
uhci0 at pci0 dev 29 function 0 "Intel 82801GB USB" rev 0x02: apic 2 int 23
uhci1 at pci0 dev 29 function 1 "Intel 82801GB USB" rev 0x02: apic 2 int 19
uhci2 at pci0 dev 29 function 2 "Intel 82801GB USB" rev 0x02: apic 2 int 18
uhci3 at pci0 dev 29 function 3 "Intel 82801GB USB" rev 0x02: apic 2 int 16
ehci0 at pci0 dev 29 function 7 "Intel 82801GB USB" rev 0x02: apic 2 int 23
usb0 at ehci0: USB revision 2.0
uhub0 at usb0 configuration 1 interface 0 "Intel EHCI root hub" rev
2.00/1.00 addr 1
ppb3 at pci0 dev 30 function 0 "Intel 82801BAM Hub-to-PCI" rev 0xe2
pci4 at ppb3 bus 5
ichpcib0 at pci0 dev 31
Re: bse: null dereference in genet_rxintr()
> Date: Wed, 20 Apr 2022 18:14:57 +0200 > From: Anton Lindqvist > > On Tue, Apr 19, 2022 at 06:07:47PM +0200, Anton Lindqvist wrote: > > On Tue, Apr 19, 2022 at 07:32:36AM +0200, Anton Lindqvist wrote: > > > On Thu, Mar 24, 2022 at 07:41:44AM +0100, Anton Lindqvist wrote: > > > > >Synopsis: bse: null dereference in genet_rxintr() > > > > >Category: arm64 > > > > >Environment: > > > > System : OpenBSD 7.1 > > > > Details : OpenBSD 7.1-beta (GENERIC.MP) #1594: Mon Mar 21 > > > > 06:55:12 MDT 2022 > > > > > > > > dera...@arm64.openbsd.org:/usr/src/sys/arch/arm64/compile/GENERIC.MP > > > > > > > > Architecture: OpenBSD.arm64 > > > > Machine : arm64 > > > > >Description: > > > > > > > > Booting my rpi4 often but not always causes a panic while rc(8) tries > > > > to start > > > > the bse network interface: > > > > > > > > panic: attempt to access user address 0x38 from EL1 > > > > Stopped at panic+0x160:cmp w21, #0x0 > > > > TIDPIDUID PRFLAGS PFLAGS CPU COMMAND > > > > * 0 0 0 0x1 0x2000K swapper > > > > db_enter() at panic+0x15c > > > > panic() at do_el1h_sync+0x1f8 > > > > do_el1h_sync() at handle_el1h_sync+0x6c > > > > handle_el1h_sync() at genet_rxintr+0x120 > > > > genet_rxintr() at genet_intr+0x74 > > > > genet_intr() at ampintc_irq_handler+0x14c > > > > ampintc_irq_handler() at arm_cpu_irq+0x30 > > > > arm_cpu_irq() at handle_el1h_irq+0x6c > > > > handle_el1h_irq() at ampintc_splx+0x80 > > > > ampintc_splx() at genet_ioctl+0x158 > > > > genet_ioctl() at ifioctl+0x308 > > > > ifioctl() at nfs_boot_init+0xc0 > > > > nfs_boot_init() at nfs_mountroot+0x3c > > > > nfs_mountroot() at main+0x464 > > > > main() at virtdone+0x70 > > > > > > > > >Fix: > > > > > > > > The mbuf associated with the current index is NULL. I noticed that the > > > > NetBSD > > > > driver allocates mbufs for each ring entry in genet_setup_dma(). But > > > > even with > > > > that in place the same panic still occurs. Enabling GENET_DEBUG shows > > > > that the > > > > total is quite high: > > > > > > > > RX pidx=ca07 total=51463 > > > > > > > > > > > > Since it's greater than GENET_DMA_DESC_COUNT (=256) the null > > > > dereference will > > > > still happen after doing more than 256 iterations in genet_rxintr() > > > > since we > > > > will start accessing mbufs cleared by the previous iteration. > > > > > > > > Here's a diff with what I've tried so far. The KASSERT() is just > > > > capturing the > > > > problem at an earlier stage. Any pointers would be much appreciated. > > > > > > Further digging reveals that writes to GENET_RX_DMA_PROD_INDEX are > > > ignored by the hardware. That's why I ended up with a large amount of > > > mbufs available in genet_rxintr() since the software and hardware state > > > was out of sync. Honoring any existing value makes the problem go away > > > and matches what u-boot[1] does as well. > > > > > > The current RX cidx/pidx defaults in genet_fill_rx_ring() where probably > > > carefully selected as they ensure that the rx ring is filled with at > > > least the configured low watermark number of mbufs. However, instead of > > > being forced to ensure a pidx - cidx delta above 0 on the first > > > invocations of genet_fill_rx_ring(), RX_DESC_COUNT could simply be > > > passed as the max argument to if_rxr_get() which will clamp the value > > > anyway. > > > > > > Also, I've seen up to 8 mbufs being available per rx interrupt which is > > > odd as only a less amount of rx ring entries are actually populated. Not > > > sure if the driver is missing some interrupt threshold configuration. > > > Increasing the rx ring low watermark to 8 "solved" it for now. > > > Otherwise, the same null dereference occurs while trying to access empty > > > mbuf ring entries. > > > > > > Worth mentioning is that the NetBSD driver does not suffer from the same > > > problem as they keep all rx ring entries populated all the time. > > > > > > Looking for feedback and OKs at this point. > > > > > > [1] > > > https://github.com/u-boot/u-boot/blob/a94ab561e2f49a80d8579930e840b810ab1a1330/drivers/net/bcmgenet.c#L404 > > > > While putting more pressure on the network I'm seeing up to 100 mbufs > > being available per rx interrupt. Could it simply be explained by the > > hardware operating under the assumption that all ring entries are > > available? Even if instructing the hardware about the actual amount of > > available ring entries would require the driver to keep it in sync > > whenever the if_rxr_*() implementation decides to adjust the ring. > > > > Moving to if_rxr_init(RX_DESC_COUNT, RX_DESC_COUNT) essentially making > > all 256 ring entries always available makes the driver stable. > > Here's the diff I've been running lately which is deemed to be stable. > Changes since last
Re: axen0: invalid buffer(pkt#1)
On Mon, 28 Mar 2022 09:25:32 +0200 Gerhard Roth wrote:
> Hi Stephan,
>
> although the newer AX88179A chip set (note the "A" at the end) uses the
> same product ID as the older AX88179, it is quite different.
>
> I will work on support for AX88179A, but that'll take some time.
>
> Regards,
>
> Gerhard
>
>
> On 3/26/22 22:05, Stephan Mending wrote:
> > Hi *,
> > I am currently in the unlucky position having to use two
> > usb-to-ethernet-adapters on a router.
> >
> > Therefore, I bought a model from "ISY" called "USB-A to Gigabit LAN Adapter
> > IAD-1010-A". You probably don't care about
> > the name of it.
> >
> > axen0 at uhub0 port 12 configuration 1 interface 0 "ASIX AX88179A" rev
> > 2.10/2.00 addr 9
> > axen0: AX88179, address f8:e4:3b:08:10:e2
> > ukphy0 at axen0 phy 3: Generic IEEE 802.3u media interface, rev. 1:
> > OUI 0x000700, model 0x0006
> >
> > The adapters are configured to act as interfaces for a local network.
> >
> > As soon as packets are received following messages are printed to
> > /var/log/messages:
> >
> > axen0: invalid buffer(pkt#1), continue
> >
> > These messages are issued with each and every packet that is received on
> > the interface.
> >
> > Taking a look at tcpdump:
> >
> > truncated-ip - 4 bytes missing!
> >
> > This message prefixes every packet that I sent towards the axen usb-adapter
> > (not just dhcp).
> > Same behavior for both of the adapters.
> >
> > Do you guys have any idea, what might be the issue?
> >
> > Best regards,
> > Stephan
> >
I got a sample driver from ASIX for the AX88179A chipset and they allow me
to use it to write a driver but they won't allow me to publish it :(
ASIX recomended to use the CDC/NCM interface of the chipset, but OpenBSD
has no driver for CDC/NCM. Looking at the USB descriptor it turns out,
that it also has a configuration for CDC/ECM.
If you try the patch below, the AX88179A should attach via cdce(4). Don't
know if this is the way to go, but at least you should be able to use
your adapters.
Good luck,
Gerhard
Index: sys/dev/usb/if_cdce.c
===
RCS file: /cvs/src/sys/dev/usb/if_cdce.c,v
retrieving revision 1.80
diff -u -p -u -p -r1.80 if_cdce.c
--- sys/dev/usb/if_cdce.c 29 Jan 2021 17:12:19 - 1.80
+++ sys/dev/usb/if_cdce.c 21 Apr 2022 11:55:15 -
@@ -59,8 +59,11 @@
#include
#include
+#include
+
#include
#include
+#include
#include
#include
#include
@@ -90,18 +93,19 @@ void cdce_stop(struct cdce_softc *);
voidcdce_intr(struct usbd_xfer *, void *, usbd_status);
const struct cdce_type cdce_devs[] = {
-{{ USB_VENDOR_ACERLABS, USB_PRODUCT_ACERLABS_M5632 }, 0 },
-{{ USB_VENDOR_PROLIFIC, USB_PRODUCT_PROLIFIC_PL2501 }, 0 },
-{{ USB_VENDOR_SHARP, USB_PRODUCT_SHARP_SL5500 }, CDCE_CRC32 },
-{{ USB_VENDOR_SHARP, USB_PRODUCT_SHARP_A300 }, CDCE_CRC32 },
-{{ USB_VENDOR_SHARP, USB_PRODUCT_SHARP_SL5600 }, CDCE_CRC32 },
-{{ USB_VENDOR_SHARP, USB_PRODUCT_SHARP_C700 }, CDCE_CRC32 },
-{{ USB_VENDOR_SHARP, USB_PRODUCT_SHARP_C750 }, CDCE_CRC32 },
-{{ USB_VENDOR_MOTOROLA2, USB_PRODUCT_MOTOROLA2_USBLAN }, CDCE_CRC32 },
-{{ USB_VENDOR_MOTOROLA2, USB_PRODUCT_MOTOROLA2_USBLAN2 }, CDCE_CRC32 },
-{{ USB_VENDOR_GMATE, USB_PRODUCT_GMATE_YP3X00 }, 0 },
-{{ USB_VENDOR_COMPAQ, USB_PRODUCT_COMPAQ_IPAQLINUX }, 0 },
-{{ USB_VENDOR_AMBIT, USB_PRODUCT_AMBIT_NTL_250 }, CDCE_SWAPUNION },
+{{ USB_VENDOR_ACERLABS, USB_PRODUCT_ACERLABS_M5632 }, 0, 0, -1 },
+{{ USB_VENDOR_PROLIFIC, USB_PRODUCT_PROLIFIC_PL2501 }, 0, 0, -1 },
+{{ USB_VENDOR_SHARP, USB_PRODUCT_SHARP_SL5500 }, 0, CDCE_CRC32, -1 },
+{{ USB_VENDOR_SHARP, USB_PRODUCT_SHARP_A300 }, 0, CDCE_CRC32, -1 },
+{{ USB_VENDOR_SHARP, USB_PRODUCT_SHARP_SL5600 }, 0, CDCE_CRC32, -1 },
+{{ USB_VENDOR_SHARP, USB_PRODUCT_SHARP_C700 }, 0, CDCE_CRC32, -1 },
+{{ USB_VENDOR_SHARP, USB_PRODUCT_SHARP_C750 }, 0, CDCE_CRC32, -1 },
+{{ USB_VENDOR_MOTOROLA2, USB_PRODUCT_MOTOROLA2_USBLAN }, 0, CDCE_CRC32, -1
},
+{{ USB_VENDOR_MOTOROLA2, USB_PRODUCT_MOTOROLA2_USBLAN2 }, 0, CDCE_CRC32,
-1 },
+{{ USB_VENDOR_GMATE, USB_PRODUCT_GMATE_YP3X00 }, 0, 0, -1 },
+{{ USB_VENDOR_COMPAQ, USB_PRODUCT_COMPAQ_IPAQLINUX }, 0, 0, -1 },
+{{ USB_VENDOR_AMBIT, USB_PRODUCT_AMBIT_NTL_250 }, 0, CDCE_SWAPUNION, -1 },
+{{ USB_VENDOR_ASIX, USB_PRODUCT_ASIX_AX88179 }, 0x0200, CDCE_MATCHREV, 3 },
};
#define cdce_lookup(v, p) \
((const struct cdce_type *)usb_lookup(cdce_devs, v, p))
@@ -123,6 +127,15 @@ cdce_match(struct device *parent, void *
{
struct usb_attach_arg *uaa = aux;
usb_interface_descriptor_t *id;
+ const struct cdce_type *type;
+
+ if ((type = cdce_lookup(uaa->vendor, uaa->product)) != NULL) {
+ if (type->cdce_flags & CDCE_MATCHREV) {
+ if (type->cdce_rev == uaa->release)
+ return
Re: rc.d/spamlogd
On 2022/04/21 10:23, Stuart Henderson wrote:
> Anyone fancy giving an explicit ok for this? Preferably someone who
> uses spamd?
Ah I missed that jturner@ already did, sorry for the noise!
>
> On 2022/04/15 22:00, Stuart Henderson wrote:
> > jturner had a problem with this, here's a diff on top of what was
> > committed.
> >
> > - I think the first line is superfluous as /etc/rc.d/rc.subr has some
> > special case for this (and I think this maybe responsible for a problem
> > which jturner ran into)
> >
> > - look for the pflog interface passed in flags and init that
> >
> > I think this is probably correct within the bounds of how spamlogd
> > currently works but some tests would be appreciated (as would
> > any improvements to the chicken scratches)
> >
> > Index: spamlogd
> > ===
> > RCS file: /cvs/src/etc/rc.d/spamlogd,v
> > retrieving revision 1.5
> > diff -u -p -r1.5 spamlogd
> > --- spamlogd11 Apr 2022 09:32:20 - 1.5
> > +++ spamlogd15 Apr 2022 21:00:10 -
> > @@ -9,11 +9,13 @@ daemon="/usr/libexec/spamlogd"
> > rc_reload=NO
> >
> > rc_pre() {
> > - [[ ${spamd_flags} != NO && ${spamd_black} == NO ]] && return 1
> > + pflog=$(echo $daemon_flags | sed -En 's/.*-l *(pflog[0-9]+).*/\1/p')
> > + pflog=${pflog:-pflog0}
> > +
> > if pfctl -si | grep -q Enabled; then
> > - ifconfig pflog0 create
> > - if ifconfig pflog0; then
> > - ifconfig pflog0 up
> > + ifconfig $pflog create
> > + if ifconfig $pflog; then
> > + ifconfig $pflog up
> > else
> > return 1
> > fi
> >
>
Re: rc.d/spamlogd
Anyone fancy giving an explicit ok for this? Preferably someone who
uses spamd?
On 2022/04/15 22:00, Stuart Henderson wrote:
> jturner had a problem with this, here's a diff on top of what was
> committed.
>
> - I think the first line is superfluous as /etc/rc.d/rc.subr has some
> special case for this (and I think this maybe responsible for a problem
> which jturner ran into)
>
> - look for the pflog interface passed in flags and init that
>
> I think this is probably correct within the bounds of how spamlogd
> currently works but some tests would be appreciated (as would
> any improvements to the chicken scratches)
>
> Index: spamlogd
> ===
> RCS file: /cvs/src/etc/rc.d/spamlogd,v
> retrieving revision 1.5
> diff -u -p -r1.5 spamlogd
> --- spamlogd 11 Apr 2022 09:32:20 - 1.5
> +++ spamlogd 15 Apr 2022 21:00:10 -
> @@ -9,11 +9,13 @@ daemon="/usr/libexec/spamlogd"
> rc_reload=NO
>
> rc_pre() {
> - [[ ${spamd_flags} != NO && ${spamd_black} == NO ]] && return 1
> + pflog=$(echo $daemon_flags | sed -En 's/.*-l *(pflog[0-9]+).*/\1/p')
> + pflog=${pflog:-pflog0}
> +
> if pfctl -si | grep -q Enabled; then
> - ifconfig pflog0 create
> - if ifconfig pflog0; then
> - ifconfig pflog0 up
> + ifconfig $pflog create
> + if ifconfig $pflog; then
> + ifconfig $pflog up
> else
> return 1
> fi
>
