urtw(4) frame validation

2011-03-20 Thread Loganaden Velvindron
Hi,

This diffs discards frame largers than 2500 bytes.

Tested on my machine:

urtw0 at uhub0 port 2 Realtek RTL8187B rev 2.00/2.00 addr 2
urtw0: RTL8187B rev E, address 00:16:44:9f:76:cb
urtw0 at uhub0 port 2 Realtek RTL8187B rev 2.00/2.00 addr 2
urtw0: RTL8187B rev E, address 00:16:44:9f:76:cb

I tested with both normal traffic,NFS, and scp.

NameMtu   Network Address  Ipkts IerrsOpkts Oerrs Colls
urtw0   1500  Link  00:16:44:9f:76:cb22989   12915563 0 0
urtw0   1500  fe80::%urtw fe80::216:44ff:fe22989   12915563 0 0
urtw0   1500  192.168.0/2 192.168.0.9  22989   12915563 0 0

No regressions here.

I'd really appreciate feedback on this, since I'm not familiar
with the wifi stack. Any Wifi guru around :-) ?

Index: src/sys/dev/usb/if_urtw.c
===
RCS file: /cvs/src/sys/dev/usb/if_urtw.c,v
retrieving revision 1.38
diff -u -p -r1.38 if_urtw.c
--- src/sys/dev/usb/if_urtw.c   25 Jan 2011 20:03:35 -  1.38
+++ src/sys/dev/usb/if_urtw.c   20 Mar 2011 06:17:35 -
@@ -3141,7 +3141,7 @@ urtw_rxeof(usbd_xfer_handle xfer, usbd_p
}
 
usbd_get_xfer_status(xfer, NULL, NULL, actlen, NULL);
-   if (actlen  URTW_MIN_RXBUFSZ) {
+   if (actlen  URTW_MIN_RXBUFSZ || actlen  URTW_RX_MAXSIZE) {
ifp-if_ierrors++;
goto skip;
}


Please test this on as many urtw(4) devices as you can.

//Logan
C-x-C-c



Re: urndis(4) Frame length validation

2011-03-20 Thread Janne Johansson
2011/3/20 Loganaden Velvindron logana...@devio.us

 Hi, this diff also discards packets larger than maximum buffer size.

 Please test.

 Index: src/sys/dev/usb/if_urndis.c
 ===
 RCS file: /cvs/src/sys/dev/usb/if_urndis.c,v
 retrieving revision 1.29
 diff -u -p -r1.29 if_urndis.c
 --- src/sys/dev/usb/if_urndis.c 25 Jan 2011 20:03:35 -  1.29
 +++ src/sys/dev/usb/if_urndis.c 20 Mar 2011 05:22:55 -
 @@ -801,12 +801,13 @@ urndis_decap(struct urndis_softc *sc, st
DPRINTF((%s: urndis_decap buffer size left %u\n,
 DEVNAME(sc),
len));

 -   if (len  sizeof(*msg)) {
 +   if (len  sizeof(*msg) || len  RNDIS_BUFSZ) {
printf(%s: urndis_decap invalid buffer len %u  
 -   minimum header %u\n,
 +   minimum header %u maximum size %d\n,
DEVNAME(sc),
len,
 -   sizeof(*msg));
 +   sizeof(*msg),
 +   RNDIS_BUFSZ);
return;
}



With this patch and doing large scp's, I get a few:

urndis0: urndis_decap invalid buffer len 1  minimum header 44 maximum size
1562
urndis0: urndis_decap invalid buffer len 1  minimum header 44 maximum size
1562

in my amd64 dmesg buffer, but no other changes noticed.

-- 
 To our sweethearts and wives.  May they never meet. -- 19th century toast



Re: urndis(4) Frame length validation

2011-03-20 Thread Loganaden Velvindron
armani@ pointed out that the checking is already done
below, so the diff is useless.

//Logan
C-x-C-c



rdist times out but will not die

2011-03-20 Thread Steven R. Gerber
I want to do local/remote mirror/backup (or should that be local-mirror
/ offsite-backup).
So a two-part question:
1.  Even if there is a timeout, shouldn't the job/process exit?
**
rdist@thedump: thedump: /mnt/mirror2/public/read_only/movies: chown from
rdist:operator to cdripper:operator
rdist@thedump: thedump:
/mnt/mirror2/public/read_only/movies/The_Thomas_Crown_Affair_1999: chown
from rdist:operator to root:operator
rdist@thedump:
/mnt/stripe2/public/read_only/movies/The_Thomas_Crown_Affair_1999/THOMAS_CROWN_AFFAIR_16X9.md5:
updating
rdist@thedump:
/mnt/stripe2/public/read_only/movies/The_Thomas_Crown_Affair_1999/THOMAS_CROWN_AFFAIR_16X9.iso:
installing
rdist@thedump: LOCAL ERROR: Response time out
rdist@thedump: updating of rdist@thedump finished
$ ps -ax|grep rdist
26025 ??  I   0:00.00 tee /var/log/rdist/2011-03-20
11059 ??  I   0:00.01 rdist -f /etc/Distfile
28446 ??  I   0:22.99 rdist: update rdist@thedump (rdist)
 7795 ??  I   1:10.32 ssh -l rdist thedump r
13045 p0  S+  0:00.00 grep rdist
**
2.  I know that they happen from time to time.  How can I avoid/prevent
timeouts? The default is 900 sec AKA 15 min?  How can this happen
between two local machines?

Thanks.



Re: [PATCH] Fix for kernel crash with udav(4) device

2011-03-20 Thread Loganaden Velvindron
With input from mk, we improved the diff.

Testing is very much appreciated.

mk@ suggests checking total_len right after xfer_status to make
sure the header is safe to use.

There's a mistake in the DPRINTF() fo RX status, one parameter is missing.
This caused another crash when debug mode is enabled.

it discards packets that are more than UDAV_BUFSZ even if the status
is correct (This is from mk@).

The datasheet mentions that a normal packet is 1522 bytes.

It works with no regression on my udav(4).

Index: src/sys/dev/usb/if_udav.c
===
RCS file: /cvs/src/sys/dev/usb/if_udav.c,v
retrieving revision 1.54
diff -u -p -r1.54 if_udav.c
--- src/sys/dev/usb/if_udav.c   20 Mar 2011 17:58:26 -  1.54
+++ src/sys/dev/usb/if_udav.c   20 Mar 2011 19:58:51 -
@@ -1128,18 +1128,25 @@ udav_rxeof(usbd_xfer_handle xfer, usbd_p
 
usbd_get_xfer_status(xfer, NULL, NULL, total_len, NULL);
 
+   if (total_len  UDAV_RX_HDRLEN) {
+   ifp-if_ierrors++;
+   goto done;
+   }
+   
h = (struct udav_rx_hdr *)c-udav_buf;
total_len = UGETW(h-length) - ETHER_CRC_LEN;

-   DPRINTF((%s: RX Status: 0x%02x\n, h-pktstat));
+   DPRINTF((%s: RX Status: 0x%02x\n, sc-sc_dev.dv_xname, h-pktstat));
 
if (h-pktstat  UDAV_RSR_LCS) {
ifp-if_collisions++;
goto done;
}
 
+   /* RX status may still be correct but total_len is bogus */
if (total_len  sizeof(struct ether_header) ||
-   h-pktstat  UDAV_RSR_ERR) {
+   h-pktstat  UDAV_RSR_ERR ||
+   total_len  UDAV_BUFSZ ) {
ifp-if_ierrors++;
goto done;
}
Index: src/sys/dev/usb/if_udavreg.h
===
RCS file: /cvs/src/sys/dev/usb/if_udavreg.h,v
retrieving revision 1.11
diff -u -p -r1.11 if_udavreg.h
--- src/sys/dev/usb/if_udavreg.h6 Dec 2010 04:41:39 -   1.11
+++ src/sys/dev/usb/if_udavreg.h20 Mar 2011 19:58:51 -
@@ -200,6 +200,6 @@ struct udav_rx_hdr {
 #define UDAV_RX_HDRLEN sizeof(struct udav_rx_hdr)
 
 /* Packet length */
-#defineUDAV_MAX_MTU1536 /* XXX: max frame size is unknown 
*/
+#defineUDAV_MAX_MTU1522 /* According to datasheet  */
 #defineUDAV_MIN_FRAME_LEN  60
 #defineUDAV_BUFSZ  UDAV_MAX_MTU + UDAV_RX_HDRLEN



Re: urndis(4) Frame length validation

2011-03-20 Thread Bryan

On 03/20/11 04:34, Janne Johansson wrote:

2011/3/20 Loganaden Velvindronlogana...@devio.us


Hi, this diff also discards packets larger than maximum buffer size.



With this patch and doing large scp's, I get a few:

urndis0: urndis_decap invalid buffer len 1  minimum header 44 maximum size
1562
urndis0: urndis_decap invalid buffer len 1  minimum header 44 maximum size
1562

in my amd64 dmesg buffer, but no other changes noticed.



on amd64, I get a few, but not as many as I did when I used it in the 
past.  This is on -current, and I have a Droid A855 running Cyanogenmod 
6.1.2 (stock android kernel, OC'ed to 800mhz with SetCPU)




uvideo(4) diff needs testing

2011-03-20 Thread Jacob Meuser
while working on an update for ffmpeg, I noticed it's ability to
record from a video(4) device is now completely broken because video(4)
doesn't yet support VIDIOC_{S,G}_PARM.

so I added support for the VIDIOC_{S,G}_PARM ioctls to video(4) and
uvideo(4).

but then ffmpeg still couldn't record from a video device.  more
investigation found that uvideo(4) doesn't fill in the timetamp
for frames when using the mmap() interface.  so I added that too.

but still, recording did not work correctly.  it would work the
first time after plugging in a camera, but not any time after that.
eventually I found that the pointer to the current frame in the
mmap() buffer does not get reset when the mmap() buffer is freed
and reallocate once that was fixed, recording video from a video(4)
device then worked like it should.

so here's a diff that includes all the above mentioned changes,
plus a few more that seemed appropriate:
* the mjpeg and uncompreeesed frame descriptors are the same,
  so use a single struct, instead of two different one.  also
  unify the handling of frame descriptors.
* really quit using the frame index from the frame descriptor
  as an index to our array of frame descriptors.  this means the
  array now starts at 0 instead of 1, which makes the code less
  confusing.
* replace magic numbers with appropriate value (sizeof(struct
  usb_video_frame_desc) to be exact)
* fill in uvideo_enum_fivals(), which is used for
  VIDIOC_ENUM_FRAMEINTERVALS ioctl

please test with uvideo(4) devices to be sure this does not break
anything that is currently working.  this will be committed in pieces,
but I wanted to get this full diff out for testing purposes.  thanks.

-- 
jake...@sdf.lonestar.org
SDF Public Access UNIX System - http://sdf.lonestar.org

Index: usb/uvideo.c
===
RCS file: /cvs/src/sys/dev/usb/uvideo.c,v
retrieving revision 1.149
diff -u -p usb/uvideo.c
--- usb/uvideo.c25 Jan 2011 20:03:36 -  1.149
+++ usb/uvideo.c20 Mar 2011 21:10:57 -
@@ -48,6 +48,7 @@
 
 #include dev/video_if.h
 
+/* #define UVIDEO_DEBUG */
 #ifdef UVIDEO_DEBUG
 int uvideo_debug = 1;
 #define DPRINTF(l, x...) do { if ((l) = uvideo_debug) printf(x); } while (0)
@@ -93,10 +94,8 @@ usbd_status  uvideo_vs_parse_desc_format_mjpeg(struct u
 usbd_statusuvideo_vs_parse_desc_format_uncompressed(struct uvideo_softc *,
const usb_descriptor_t *);
 usbd_statusuvideo_vs_parse_desc_frame(struct uvideo_softc *);
-usbd_statusuvideo_vs_parse_desc_frame_mjpeg(struct uvideo_softc *,
+usbd_statusuvideo_vs_parse_desc_frame_sub(struct uvideo_softc *,
const usb_descriptor_t *);
-usbd_statusuvideo_vs_parse_desc_frame_uncompressed(struct uvideo_softc *,
-   const usb_descriptor_t *);
 usbd_statusuvideo_vs_parse_desc_alt(struct uvideo_softc *, int, int, int);
 usbd_statusuvideo_vs_set_alt(struct uvideo_softc *, usbd_interface_handle,
int);
@@ -152,13 +151,11 @@ void  uvideo_dump_desc_cs_endpoint(struct 
uvideo_softc
const usb_descriptor_t *);
 void   uvideo_dump_desc_colorformat(struct uvideo_softc *,
const usb_descriptor_t *);
-void   uvideo_dump_desc_frame_mjpeg(struct uvideo_softc *,
-   const usb_descriptor_t *);
 void   uvideo_dump_desc_format_mjpeg(struct uvideo_softc *,
const usb_descriptor_t *);
 void   uvideo_dump_desc_format_uncompressed(struct uvideo_softc *,
const usb_descriptor_t *);
-void   uvideo_dump_desc_frame_uncompressed(struct uvideo_softc *,
+void   uvideo_dump_desc_frame(struct uvideo_softc *,
const usb_descriptor_t *);
 void   uvideo_dump_desc_processing(struct uvideo_softc *,
const usb_descriptor_t *);
@@ -178,6 +175,8 @@ int uvideo_enum_fsizes(void *, struct 
v4l2_frmsizeenu
 intuvideo_enum_fivals(void *, struct v4l2_frmivalenum *);
 intuvideo_s_fmt(void *, struct v4l2_format *);
 intuvideo_g_fmt(void *, struct v4l2_format *);
+intuvideo_s_parm(void *, struct v4l2_streamparm *);
+intuvideo_g_parm(void *, struct v4l2_streamparm *);
 intuvideo_enum_input(void *, struct v4l2_input *);
 intuvideo_s_input(void *, int);
 intuvideo_reqbufs(void *, struct v4l2_requestbuffers *);
@@ -225,6 +224,8 @@ struct video_hw_if uvideo_hw_if = {
uvideo_enum_fivals, /* VIDIOC_ENUM_FRAMEINTERVALS */
uvideo_s_fmt,   /* VIDIOC_S_FMT */
uvideo_g_fmt,   /* VIDIOC_G_FMT */
+   uvideo_s_parm,  /* VIDIOC_S_PARM */
+   uvideo_g_parm,  /* VIDIOC_G_PARM */
uvideo_enum_input,  /* VIDIOC_ENUMINPUT */
uvideo_s_input, /* VIDIOC_S_INPUT */
uvideo_reqbufs, /*