Re: install.sub: ieee80211_{scan,config}: Allow quoted SSIDs

[Klemens Nanni]

On Fri, Sep 06, 2019 at 11:01:35PM +0200, Klemens Nanni wrote:
> I'd like to finally commit this so occasional installations over said
> wifi will just work.
I'll commit this weekend unless someone objects.

Re: once again: iwm(4) multi-frame rx + monitor mode

[Mikolaj Kucharski]

Hi Stefan,

On Fri, Sep 13, 2019 at 02:10:12PM +0200, Stefan Sperling wrote:
> Updated diff, rebased on top of -current
> 
> If you were seeing throughput problems when testing this diff in the
> previous round, please try again.
> 
> I suspect such problems were due to the ifq drop issue which has since
> been fixed in -current. The diff below results in more packets per interrupt
> being delivered to the network stack which is exactly what made ifq drops
> more likely to occur. This should no longer be an issue.
> 
> I have tested this diff on 8265 and 7260 and I don't see any problems.

iwm0 at pci2 dev 0 function 0 "Intel Dual Band Wireless-AC 8265" rev 0x78, msi
iwm0: hw rev 0x230, fw ver 22.361476.0, address 38:37:8b:XX:XX:XX

I've tested monitor mode and it seems to work:

$ ifconfig iwm0
iwm0: flags=8847 mtu 1500
lladdr 38:37:8b:XX:XX:XX
index 1 priority 4 llprio 3
groups: wlan egress
media: IEEE802.11 autoselect monitor
status: active
ieee80211: nwid linksys chan 11 bssid 00:1d:7e:XX:XX:XX 29%

I've used kismet-201607R1p0 package and I could see networks and packets
being reported. Testing with tcpdump(8) also showed traffic visible from
various access points around:

# tcpdump -c 3 -y IEEE802_11_RADIO -ni iwm0  
tcpdump: listening on iwm0, link-type IEEE802_11_RADIO
21:25:12.586606 802.11: beacon, ssid (net_092382), rates, ds, tim, xrates, rsn, 
htcaps, 
21:25:12.653411 802.11: beacon, ssid (linksys), rates, ds, tim, erp, 47:1, 
xrates, vendor, 
21:25:12.755803 802.11: beacon, ssid (linksys), rates, ds, tim, erp, 47:1, 
xrates, vendor, 

I see in tcpdump output that all beacons are reported with chan 11,
where I know some of the access points are not on channel 11. Not
sure is this expected. Other than that, I don't see anything
concerning.

Regards,
 Mikolaj

> diff refs/heads/master refs/heads/iwm-multirx
> blob - 20ce2cbe3d2c2994b9a498965a3c9f29a5f31c9c
> blob + d3baf8473bd86beb05eaed7eb6cb715f90790c46
> --- sys/dev/pci/if_iwm.c
> +++ sys/dev/pci/if_iwm.c
> @@ -367,8 +367,10 @@ int  iwm_get_signal_strength(struct iwm_softc *, 
> struct
>  void iwm_rx_rx_phy_cmd(struct iwm_softc *, struct iwm_rx_packet *,
>   struct iwm_rx_data *);
>  int  iwm_get_noise(const struct iwm_statistics_rx_non_phy *);
> -void iwm_rx_rx_mpdu(struct iwm_softc *, struct iwm_rx_packet *,
> - struct iwm_rx_data *, struct mbuf_list *);
> +int  iwm_rx_frame(struct iwm_softc *, struct mbuf *, uint32_t,
> + struct mbuf_list *);
> +int  iwm_ccmp_decap(struct iwm_softc *, struct mbuf *,
> + struct ieee80211_node *);
>  void iwm_enable_ht_cck_fallback(struct iwm_softc *, struct iwm_node *);
>  void iwm_rx_tx_cmd_single(struct iwm_softc *, struct iwm_rx_packet *,
>   struct iwm_node *);
> @@ -429,7 +431,7 @@ uint8_t   iwm_ridx2rate(struct ieee80211_rateset *, int)
>  int  iwm_rval2ridx(int);
>  void iwm_ack_rates(struct iwm_softc *, struct iwm_node *, int *, int *);
>  void iwm_mac_ctxt_cmd_common(struct iwm_softc *, struct iwm_node *,
> - struct iwm_mac_ctx_cmd *, uint32_t, int);
> + struct iwm_mac_ctx_cmd *, uint32_t);
>  void iwm_mac_ctxt_cmd_fill_sta(struct iwm_softc *, struct iwm_node *,
>   struct iwm_mac_data_sta *, int);
>  int  iwm_mac_ctxt_cmd(struct iwm_softc *, struct iwm_node *, uint32_t, int);
> @@ -470,6 +472,11 @@ const char *iwm_desc_lookup(uint32_t);
>  void iwm_nic_error(struct iwm_softc *);
>  void iwm_nic_umac_error(struct iwm_softc *);
>  #endif
> +void iwm_rx_mpdu(struct iwm_softc *, struct mbuf *, size_t,
> + struct mbuf_list *);
> +int  iwm_rx_pkt_valid(struct iwm_rx_packet *);
> +void iwm_rx_pkt(struct iwm_softc *, struct iwm_rx_data *,
> + struct mbuf_list *);
>  void iwm_notif_intr(struct iwm_softc *);
>  int  iwm_intr(void *);
>  int  iwm_match(struct device *, void *, void *);
> @@ -1723,7 +1730,6 @@ iwm_nic_rx_init(struct iwm_softc *sc)
>   IWM_FH_RCSR_RX_CONFIG_CHNL_EN_ENABLE_VAL|
>   IWM_FH_RCSR_CHNL0_RX_IGNORE_RXF_EMPTY   |  /* HW bug */
>   IWM_FH_RCSR_CHNL0_RX_CONFIG_IRQ_DEST_INT_HOST_VAL   |
> - IWM_FH_RCSR_CHNL0_RX_CONFIG_SINGLE_FRAME_MSK|
>   (IWM_RX_RB_TIMEOUT << IWM_FH_RCSR_RX_CONFIG_REG_IRQ_RBTH_POS) |
>   IWM_FH_RCSR_RX_CONFIG_REG_VAL_RB_SIZE_4K|
>   IWM_RX_QUEUE_SIZE_LOG << IWM_FH_RCSR_RX_CONFIG_RBDCB_SIZE_POS);
> @@ -3429,56 +3435,24 @@ iwm_get_noise(const struct iwm_statistics_rx_non_phy *
>   return (nbant == 0) ? -127 : (total / nbant) - 107;
>  }
>  
> -void
> -iwm_rx_rx_mpdu(struct iwm_softc *sc, struct iwm_rx_packet *pkt,
> -struct iwm_rx_data *data, struct mbuf_list *ml)
> +int
> +iwm_rx_frame(struct iwm_softc *sc, struct mbuf *m, uint32_t rx_pkt_status,
> +struct mbuf_list *ml)
>  {
>   struct ieee80211com *ic = >sc_ic;
>   struct ieee80211_frame *wh;
>   struct ieee80211_node *ni;
>   struct ieee80211_rxinfo rxi;
>   

httpd parse.y patch

[Edgar Pettijohn]

Remove unused struct.


Index: parse.y
===
RCS file: /cvs/src/usr.sbin/httpd/parse.y,v
retrieving revision 1.113
diff -u -p -u -p -r1.113 parse.y
--- parse.y 28 Jun 2019 13:32:47 -  1.113
+++ parse.y 13 Sep 2019 20:41:26 -
@@ -124,10 +124,6 @@ typedef struct {
struct timeval   tv;
struct portrange port;
struct auth  auth;
-   struct {
-   struct sockaddr_storage  ss;
-   char name[HOST_NAME_MAX+1];
-   }addr;
} v;
int lineno;
 } YYSTYPE;

PATCH: smtpd: don't strcmp() NULL in mta_relay_cmp()

[Caspar Schutijser]

Hi,

smtpd crashed on one of my machines. I attempted to start it again but
it crashed again after a few seconds.

After doing
  # sysctl kern.nosuidcoredump=3
  # mkdir -m 700 /var/crash/smtpd
and rebuilding smtpd with DEBUG=-g I obtained the following information:


# egdb /usr/src/usr.sbin/smtpd/smtpd/smtpd 4142.core  
GNU gdb (GDB) 7.12.1
Copyright (C) 2017 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later 
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
and "show warranty" for details.
This GDB was configured as "x86_64-unknown-openbsd6.6".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
.
Find the GDB manual and other documentation resources online at:
.
For help, type "help".
Type "apropos word" to search for commands related to "word"...
Reading symbols from /usr/src/usr.sbin/smtpd/smtpd/smtpd...done.
Illegal process-id: 4142.core.
[New process 382296]
Core was generated by `smtpd'.
Program terminated with signal SIGSEGV, Segmentation fault.
#0  strcmp () at /usr/src/lib/libc/arch/amd64/string/strcmp.S:47
47  movq8(%rsi),%rdx
(gdb) frame 1
#1  0x06b086ba3478 in mta_relay_cmp (a=0x7f7c5e90, b=0x6b34ad15200) at 
../mta.c:2077
2077if (a->backupname && ((r = strcmp(a->backupname, 
b->backupname
(gdb) print a->backupname
$1 = 0x6b2c800f9a0 "tank.msrv.nl"
(gdb) print b->backupname
$2 = 0x0


So I think the problem is that b->backupname is passed to strcmp()
without checking whether b->backupname != NULL. The diff below adds
such a check, in line with other string comparisons that are performed
in mta_relay_cmp(). In the same function, I think the same problem
exists while comparing a->authlabel and b->authlabel so I added a
similar check there.

I'd like you to double-check whether the fix is indeed correct.

Thanks,
Caspar Schutijser


Index: mta.c
===
RCS file: /cvs/src/usr.sbin/smtpd/mta.c,v
retrieving revision 1.228
diff -u -p -r1.228 mta.c
--- mta.c   14 Jun 2019 19:55:25 -  1.228
+++ mta.c   13 Sep 2019 19:28:02 -
@@ -2036,6 +2036,10 @@ mta_relay_cmp(const struct mta_relay *a,
return (1);
if (a->authtable && ((r = strcmp(a->authtable, b->authtable
return (r);
+   if (a->authlabel == NULL && b->authlabel)
+   return (-1);
+   if (a->authlabel && b->authlabel == NULL)
+   return (1);
if (a->authlabel && ((r = strcmp(a->authlabel, b->authlabel
return (r);
if (a->sourcetable == NULL && b->sourcetable)
@@ -2071,6 +2075,10 @@ mta_relay_cmp(const struct mta_relay *a,
if (a->ca_name && ((r = strcmp(a->ca_name, b->ca_name
return (r);
 
+   if (a->backupname == NULL && b->backupname)
+   return (-1);
+   if (a->backupname && b->backupname == NULL)
+   return (1);
if (a->backupname && ((r = strcmp(a->backupname, b->backupname
return (r);
 

ftpd: vfprintf %s NULL in "Opening %s mode data connection for '%s'%s."

[Raf Czlonka]

Hi all,

I've used the base ftpd(8) today:

$ echo $USER | doas tee -a /etc/ftpchroot
$ doas rcctl enable ftpd
$ doas rcctl start ftpd

And, after connecting to it:

$ ftp localhost

authenticating, and listing the content of the directory, I found
this message in /var/log/messages:

ftpd: vfprintf %s NULL in "Opening %s mode data connection for '%s'%s."

I can't seem to be able to reproduce it but it appeared in the logs
twice in the last 5 minutes.

Regards,

Raf

Re: once again: iwm(4) multi-frame rx + monitor mode

[Stefan Sperling]

On Fri, Aug 30, 2019 at 03:59:08PM +0200, Stefan Sperling wrote:
> I would like to try this again: In iwm(4), process more than one frame
> per Rx interrupt, and enable monitor mode.
> 
> Monitor mode triggers "unhandled fimware response" errors without multi-Rx
> support. We have seen these infamous errors in other contexts as well.
> It is possible that the firmware decides to use multi-Rx in such cases
> which would of course confuse our driver.
> 
> The fact is that Linux has not used single-Rx mode for years. One of their
> developers told me that Intel has stopped testing it entirely. The current
> code isn't future-proof and is likely to break with newer versions of
> firmware and/or hardware.

Updated diff, rebased on top of -current

If you were seeing throughput problems when testing this diff in the
previous round, please try again.

I suspect such problems were due to the ifq drop issue which has since
been fixed in -current. The diff below results in more packets per interrupt
being delivered to the network stack which is exactly what made ifq drops
more likely to occur. This should no longer be an issue.

I have tested this diff on 8265 and 7260 and I don't see any problems.

diff refs/heads/master refs/heads/iwm-multirx
blob - 20ce2cbe3d2c2994b9a498965a3c9f29a5f31c9c
blob + d3baf8473bd86beb05eaed7eb6cb715f90790c46
--- sys/dev/pci/if_iwm.c
+++ sys/dev/pci/if_iwm.c
@@ -367,8 +367,10 @@ intiwm_get_signal_strength(struct iwm_softc *, 
struct
 void   iwm_rx_rx_phy_cmd(struct iwm_softc *, struct iwm_rx_packet *,
struct iwm_rx_data *);
 intiwm_get_noise(const struct iwm_statistics_rx_non_phy *);
-void   iwm_rx_rx_mpdu(struct iwm_softc *, struct iwm_rx_packet *,
-   struct iwm_rx_data *, struct mbuf_list *);
+intiwm_rx_frame(struct iwm_softc *, struct mbuf *, uint32_t,
+   struct mbuf_list *);
+intiwm_ccmp_decap(struct iwm_softc *, struct mbuf *,
+   struct ieee80211_node *);
 void   iwm_enable_ht_cck_fallback(struct iwm_softc *, struct iwm_node *);
 void   iwm_rx_tx_cmd_single(struct iwm_softc *, struct iwm_rx_packet *,
struct iwm_node *);
@@ -429,7 +431,7 @@ uint8_t iwm_ridx2rate(struct ieee80211_rateset *, int)
 intiwm_rval2ridx(int);
 void   iwm_ack_rates(struct iwm_softc *, struct iwm_node *, int *, int *);
 void   iwm_mac_ctxt_cmd_common(struct iwm_softc *, struct iwm_node *,
-   struct iwm_mac_ctx_cmd *, uint32_t, int);
+   struct iwm_mac_ctx_cmd *, uint32_t);
 void   iwm_mac_ctxt_cmd_fill_sta(struct iwm_softc *, struct iwm_node *,
struct iwm_mac_data_sta *, int);
 intiwm_mac_ctxt_cmd(struct iwm_softc *, struct iwm_node *, uint32_t, int);
@@ -470,6 +472,11 @@ const char *iwm_desc_lookup(uint32_t);
 void   iwm_nic_error(struct iwm_softc *);
 void   iwm_nic_umac_error(struct iwm_softc *);
 #endif
+void   iwm_rx_mpdu(struct iwm_softc *, struct mbuf *, size_t,
+   struct mbuf_list *);
+intiwm_rx_pkt_valid(struct iwm_rx_packet *);
+void   iwm_rx_pkt(struct iwm_softc *, struct iwm_rx_data *,
+   struct mbuf_list *);
 void   iwm_notif_intr(struct iwm_softc *);
 intiwm_intr(void *);
 intiwm_match(struct device *, void *, void *);
@@ -1723,7 +1730,6 @@ iwm_nic_rx_init(struct iwm_softc *sc)
IWM_FH_RCSR_RX_CONFIG_CHNL_EN_ENABLE_VAL|
IWM_FH_RCSR_CHNL0_RX_IGNORE_RXF_EMPTY   |  /* HW bug */
IWM_FH_RCSR_CHNL0_RX_CONFIG_IRQ_DEST_INT_HOST_VAL   |
-   IWM_FH_RCSR_CHNL0_RX_CONFIG_SINGLE_FRAME_MSK|
(IWM_RX_RB_TIMEOUT << IWM_FH_RCSR_RX_CONFIG_REG_IRQ_RBTH_POS) |
IWM_FH_RCSR_RX_CONFIG_REG_VAL_RB_SIZE_4K|
IWM_RX_QUEUE_SIZE_LOG << IWM_FH_RCSR_RX_CONFIG_RBDCB_SIZE_POS);
@@ -3429,56 +3435,24 @@ iwm_get_noise(const struct iwm_statistics_rx_non_phy *
return (nbant == 0) ? -127 : (total / nbant) - 107;
 }
 
-void
-iwm_rx_rx_mpdu(struct iwm_softc *sc, struct iwm_rx_packet *pkt,
-struct iwm_rx_data *data, struct mbuf_list *ml)
+int
+iwm_rx_frame(struct iwm_softc *sc, struct mbuf *m, uint32_t rx_pkt_status,
+struct mbuf_list *ml)
 {
struct ieee80211com *ic = >sc_ic;
struct ieee80211_frame *wh;
struct ieee80211_node *ni;
struct ieee80211_rxinfo rxi;
struct ieee80211_channel *bss_chan;
-   struct mbuf *m;
struct iwm_rx_phy_info *phy_info;
-   struct iwm_rx_mpdu_res_start *rx_res;
int device_timestamp;
-   uint32_t len;
-   uint32_t rx_pkt_status;
int rssi, chanidx;
uint8_t saved_bssid[IEEE80211_ADDR_LEN] = { 0 };
 
-   bus_dmamap_sync(sc->sc_dmat, data->map, 0, IWM_RBUF_SIZE,
-   BUS_DMASYNC_POSTREAD);
-
phy_info = >sc_last_phy_info;
-   rx_res = (struct iwm_rx_mpdu_res_start *)pkt->data;
-   wh = (struct ieee80211_frame *)(pkt->data + sizeof(*rx_res));
-   len = le16toh(rx_res->byte_count);
-   if (len < IEEE80211_MIN_LEN) {
-