You know, this could be wi(4) losing. Weren't you having panics in
wi_read_bap? Please send me your whole dmesg, and ifconfig wi0, for
my collection.

Apply this patch, which protects against bogus frame lengths.

Index: wi.c
===================================================================
RCS file: /cvsroot/src/sys/dev/ic/wi.c,v
retrieving revision 1.107
diff -c -r1.107 wi.c
*** wi.c        2003/01/01 02:06:47     1.107
--- wi.c        2003/01/05 21:20:15
***************
*** 1154,1159 ****
--- 1565,1577 ----
        len = le16toh(frmhdr.wi_dat_len);
        off = ALIGN(sizeof(struct ieee80211_frame));
  
+       if (off + len > MCLBYTES) {
+               CSR_WRITE_2(sc, WI_EVENT_ACK, WI_EV_RX);
+               ifp->if_ierrors++;
+               DPRINTF(("wi_rx_intr: oversized packet\n"));
+               return;
+       }
+ 
        MGETHDR(m, M_DONTWAIT, MT_DATA);
        if (m == NULL) {
                CSR_WRITE_2(sc, WI_EVENT_ACK, WI_EV_RX);


Dave

On Sun, Jan 05, 2003 at 01:16:49PM +1100, Paul Ripke wrote:
> My general firewall/router/gateway box running NetBSD current from
> around 2003-01-01 runs a transparent web proxy using NAT to redirect
> outbound port 80 connections through to squid on port 3128. After
> upgrading from an October(ish) kernel to current, I've started seeing
> TCP connections hanging between squid and a MacOSX laptop on my
> internal wireless network. This doesn't happen when my laptop is on
> my internal ethernet network (using the same transparent proxy).
> Nor does it happen when I manually configure the proxy - indicating
> a possible problem in the ipf/NAT code?
> 
> Here's a trace from the laptop. I'm no good reading traces at this
> level of detail, but it looks like something is breaking with the
> FIN handling. Someone want to tell me what's going on here?
> 
> 12:18:00.498254 192.168.254.130.49753 > 203.63.53.112.80: . ack 19649 
> win 33304 <nop,nop,timestamp 204410 3> (DF)
> 12:18:00.529706 203.63.53.112.80 > 192.168.254.130.49753: P 
> 19649:20745(1096) ack 1518 win 32850 <nop,nop,timestamp 3 204409> (DF)
> 12:18:00.563885 203.63.53.112.80 > 192.168.254.130.49753: . 
> 20745:22193(1448) ack 1518 win 32850 <nop,nop,timestamp 3 204409> (DF)
> 12:18:00.593888 203.63.53.112.80 > 192.168.254.130.49753: . 
> 22193:23641(1448) ack 1518 win 32850 <nop,nop,timestamp 3 204409> (DF)
> 12:18:00.594436 192.168.254.130.49753 > 203.63.53.112.80: . ack 23641 
> win 33304 <nop,nop,timestamp 204410 3> (DF)
> 12:18:00.629632 203.63.53.112.80 > 192.168.254.130.49753: P 
> 23641:24841(1200) ack 1518 win 32850 <nop,nop,timestamp 3 204409> (DF)
> 12:18:00.663462 203.63.53.112.80 > 192.168.254.130.49753: . 
> 24841:26289(1448) ack 1518 win 32850 <nop,nop,timestamp 3 204409> (DF)
> 12:18:00.703491 203.63.53.112.80 > 192.168.254.130.49753: . 
> 26289:27737(1448) ack 1518 win 32850 <nop,nop,timestamp 3 204409> (DF)
> 12:18:00.703899 192.168.254.130.49753 > 203.63.53.112.80: . ack 27737 
> win 33304 <nop,nop,timestamp 204410 3> (DF)
> 12:18:00.739563 203.63.53.112.80 > 192.168.254.130.49753: P 
> 27737:28937(1200) ack 1518 win 32850 <nop,nop,timestamp 3 204409> (DF)
> 12:18:00.777821 203.63.53.112.80 > 192.168.254.130.49753: . 
> 28937:30385(1448) ack 1518 win 32850 <nop,nop,timestamp 3 204409> (DF)
> 12:18:00.807660 203.63.53.112.80 > 192.168.254.130.49753: P 
> 30385:31437(1052) ack 1518 win 32850 <nop,nop,timestamp 3 204409> (DF)
> 12:18:00.808042 192.168.254.130.49753 > 203.63.53.112.80: . ack 31437 
> win 33304 <nop,nop,timestamp 204410 3> (DF)
> 12:20:01.188054 203.63.53.112.80 > 192.168.254.130.49753: F 
> 31437:31437(0) ack 1518 win 32850 <nop,nop,timestamp 244 204409> (DF)
> 12:20:01.188276 192.168.254.130.49753 > 203.63.53.112.80: . ack 31438 
> win 33304 <nop,nop,timestamp 204651 244> (DF)
> 12:20:12.903176 192.168.254.130.49753 > 203.63.53.112.80: F 
> 1518:1518(0) ack 31438 win 33304 <nop,nop,timestamp 204674 244> (DF)
> 12:20:12.906652 203.63.53.112.80 > 192.168.254.130.49753: . ack 1519 
> win 32850 <nop,nop,timestamp 268 204674> (DF)
> 
> Cheers,
> --
> Paul Ripke
> Unix/OpenVMS/DBA
> 101 reasons why you can't find your Sysadmin:
> 68: It's 9AM. He/She is not working that late.
> -- Koos van den Hout

-- 
David Young             OJC Technologies
dyoung@ojctech.com      Engineering from the Right Brain
                        Urbana, IL * (217) 278-3933