Re: Byte range implementation for httpd(8)
Sorry for the very late reply, I'm currently very busy :/
On Fri, Apr 17, 2015 at 05:04:01AM +0200, Sunil Nimmagadda wrote:
Range requests as defined in RFC7233 is required for resuming
interrupted http(s) downloads for example:
ftp -C http://foo.bar/install57.iso
With this diff, httpd parses Range header in the requests and
provide either 206(Partial Content) or 416(Range not Satisfiable)
responses with Content-Range header set appropriately. Further,
it understands multi range request and generate satisfiable payloads
with multipart/byteranges media type.
Suggestions/comments to improve the diff are welcome.
Note, If-Range isn't implemented yet.
Index: server_file.c
===
RCS file: /cvs/src/usr.sbin/httpd/server_file.c,v
retrieving revision 1.51
diff -u -p -r1.51 server_file.c
--- server_file.c 12 Feb 2015 10:05:29 - 1.51
+++ server_file.c 17 Apr 2015 02:22:12 -
@@ -36,12 +36,23 @@
#define MINIMUM(a, b)(((a) (b)) ? (a) : (b))
#define MAXIMUM(a, b)(((a) (b)) ? (a) : (b))
+#define MAX_RANGES 4
+
+struct range {
+ off_t start;
+ off_t end;
+};
int server_file_access(struct httpd *, struct client *, char *, size_t);
int server_file_request(struct httpd *, struct client *, char *,
struct stat *);
+int server_partial_file_request(struct httpd *, struct client *, char *,
+ struct stat *, char *);
int server_file_index(struct httpd *, struct client *, struct stat *);
int server_file_method(struct client *);
+int parse_range_spec(char *, size_t, struct range *);
+struct range *parse_range(char *, size_t, int *);
+int buffer_add_range(int, struct evbuffer *, struct range *);
This whole block now needs another tab indentation after the type
(except for parse_range of course)
int
server_file_access(struct httpd *env, struct client *clt,
@@ -50,6 +61,7 @@ server_file_access(struct httpd *env, st
struct http_descriptor *desc = clt-clt_descreq;
struct server_config*srv_conf = clt-clt_srv_conf;
struct stat st;
+ struct kv *r, key;
char*newpath;
int ret;
@@ -123,7 +135,13 @@ server_file_access(struct httpd *env, st
goto fail;
}
- return (server_file_request(env, clt, path, st));
+ key.kv_key = Range;
+ r = kv_find(desc-http_headers, key);
+ if (r != NULL)
+ return (server_partial_file_request(env, clt, path, st,
+ r-kv_value));
+ else
+ return (server_file_request(env, clt, path, st));
fail:
switch (errno) {
@@ -262,6 +280,138 @@ server_file_request(struct httpd *env, s
}
int
+server_partial_file_request(struct httpd *env, struct client *clt, char
*path,
+struct stat *st, char *range_str)
+{
+ struct http_descriptor *resp = clt-clt_descresp;
+ struct media_type *media, multipart_media;
+ struct range*range;
+ struct evbuffer *evb = NULL;
+ size_t content_length;
+ int code = 500, fd = -1, i, nranges, ret;
+ char content_range[64];
+ const char *errstr = NULL;
+ uint32_t boundary;
Nit: uint32_t should be below int
+
this is missing the server_file_method() song and dance from
server_file_request()
+ if ((range = parse_range(range_str, st-st_size, nranges)) == NULL) {
+ code = 416;
+ (void)snprintf(content_range, sizeof(content_range),
+ bytes */%lld, st-st_size);
+ errstr = content_range;
+ goto abort;
+ }
hm, apache answers with the full file and 200 if the range header is
syntactically incorrect or if end start. As far as I can tell it
only answers 416 if the range actually lies outside of the file.
+
+ /* Now open the file, should be readable or we have another problem */
+ if ((fd = open(path, O_RDONLY)) == -1)
+ goto abort;
+
+ media = media_find(env-sc_mediatypes, path);
+ if ((evb = evbuffer_new()) == NULL) {
+ errstr = failed to allocate file buffer;
+ goto abort;
+ }
+
+ if (nranges == 1) {
+ (void)snprintf(content_range, sizeof(content_range),
+ bytes %lld-%lld/%lld, range-start, range-end,
+ st-st_size);
+ if (kv_add(resp-http_headers, Content-Range,
+ content_range) == NULL)
+ goto abort;
+
+ content_length = range-end - range-start + 1;
+ if (buffer_add_range(fd, evb, range) == 0)
+ goto abort;
+
+ } else {
+ content_length = 0;
+ boundary = arc4random();
+ /*
[PATCH] Man pages: usbd_open_pipe(9), usbd_close_pipe(9)
Hi tech@, This patch adds man pages for usbd_open_pipe, usbd_open_pipe_intr, usbd_close_pipe and usbd_abort_pipe, done as two files: usbd_open_pipe.9 and usbd_close_pipe.9. It also adds these two new .9 files to the appropriate Makefile and tweaks usbd_transfer(9) to refer to usbd_open_pipe(9). Comments, feedback most welcome. Pax, -A P.S. I f'ing love mandoc. Just sayin... -- att...@stalphonsos.com | http://trac.haqistan.net/~attila keyid E6CC1EDB | 4D91 1B98 A210 1D71 2A0E AC29 9677 D0A6 E6CC 1EDB Index: Makefile === RCS file: /cvs/src/share/man/man9/Makefile,v retrieving revision 1.230 diff -u -p -r1.230 Makefile --- Makefile 10 Feb 2015 21:56:08 - 1.230 +++ Makefile 2 May 2015 00:07:16 - @@ -31,7 +31,7 @@ MAN= aml_evalnode.9 atomic_add_int.9 ato tsleep.9 spl.9 startuphook_establish.9 \ socreate.9 sosplice.9 style.9 syscall.9 systrace.9 sysctl_int.9 \ task_add.9 tc_init.9 time.9 timeout.9 tvtohz.9 uiomove.9 uvm.9 \ - usbd_transfer.9 \ + usbd_transfer.9 usbd_open_pipe.9 usbd_close_pipe.9 \ vfs.9 vfs_busy.9 \ vfs_cache.9 vaccess.9 vclean.9 vcount.9 vdevgone.9 vfinddev.9 vflush.9 \ vflushbuf.9 vget.9 vgone.9 vhold.9 vinvalbuf.9 vnode.9 vnsubr.9 \ Index: usbd_close_pipe.9 === RCS file: usbd_close_pipe.9 diff -N usbd_close_pipe.9 --- /dev/null 1 Jan 1970 00:00:00 - +++ usbd_close_pipe.9 2 May 2015 00:07:16 - @@ -0,0 +1,59 @@ +.\ $OpenBSD$ +.\ +.\ Copyright (c) 2015 Sean Levy att...@stalphonsos.com +.\ +.\ Permission to use, copy, modify, and distribute this software for any +.\ purpose with or without fee is hereby granted, provided that the above +.\ copyright notice and this permission notice appear in all copies. +.\ +.\ THE SOFTWARE IS PROVIDED AS IS AND THE AUTHOR DISCLAIMS ALL WARRANTIES +.\ WITH REGARD TO THIS SOFTWARE INCLUDING ALL IMPLIED WARRANTIES OF +.\ MERCHANTABILITY AND FITNESS. IN NO EVENT SHALL THE AUTHOR BE LIABLE FOR +.\ ANY SPECIAL, DIRECT, INDIRECT, OR CONSEQUENTIAL DAMAGES OR ANY DAMAGES +.\ WHATSOEVER RESULTING FROM LOSS OF USE, DATA OR PROFITS, WHETHER IN AN +.\ ACTION OF CONTRACT, NEGLIGENCE OR OTHER TORTIOUS ACTION, ARISING OUT OF +.\ OR IN CONNECTION WITH THE USE OR PERFORMANCE OF THIS SOFTWARE. +.\ +.Dd $Mdocdate$ +.Dt USBD_CLOSE_PIPE 9 +.Os +.Sh NAME +.Nm usbd_close_pipe , usbd_abort_pipe +.Nd close or abort transfers on a USB pipe +.Sh SYNOPSIS +.In dev/usb/usb.h +.In dev/usb/usbdi.h +.Ft usbd_status +.Fn usbd_close_pipe struct usbd_pipe *pipe +.Ft usbd_status +.Fn usbd_abort_pipe struct usbd_pipe *pipe +.Sh DESCRIPTION +A pipe is a logical connection between the host and an endpoint +on a USB device, created by one of +.Xr usbd_open_pipe 9 +or +.Xr usbd_open_pipe_intr 9 . +.Pp +The +.Fn usbd_abort_pipe +function aborts any transfers queued on the pipe and ensures it is quiescent +before returning. +.Pp +The +.Fn usbd_close_pipe +function first calls +.Fn usbd_abort_pipe , +then removes the pipe from the relevant USB interface's list of pipes +and cleans up any memory associated with the pipe, including any +implicit transfer created by +.Xr usbd_open_pipe_intr 9 . +.Sh CONTEXT +.Fn usbd_abort_pipe +and +.Fn usbd_close_pipe +can be called during autoconf, from process context or from interrupt +context. +.Sh SEE ALSO +.Xr usbd_open_pipe 9 , +.Xr usb 4 , +.Xr intro 4 Index: usbd_open_pipe.9 === RCS file: usbd_open_pipe.9 diff -N usbd_open_pipe.9 --- /dev/null 1 Jan 1970 00:00:00 - +++ usbd_open_pipe.9 2 May 2015 00:07:16 - @@ -0,0 +1,162 @@ +.\ $OpenBSD$ +.\ +.\ Copyright (c) 2015 Sean Levy att...@stalphonsos.com +.\ +.\ Permission to use, copy, modify, and distribute this software for any +.\ purpose with or without fee is hereby granted, provided that the above +.\ copyright notice and this permission notice appear in all copies. +.\ +.\ THE SOFTWARE IS PROVIDED AS IS AND THE AUTHOR DISCLAIMS ALL WARRANTIES +.\ WITH REGARD TO THIS SOFTWARE INCLUDING ALL IMPLIED WARRANTIES OF +.\ MERCHANTABILITY AND FITNESS. IN NO EVENT SHALL THE AUTHOR BE LIABLE FOR +.\ ANY SPECIAL, DIRECT, INDIRECT, OR CONSEQUENTIAL DAMAGES OR ANY DAMAGES +.\ WHATSOEVER RESULTING FROM LOSS OF USE, DATA OR PROFITS, WHETHER IN AN +.\ ACTION OF CONTRACT, NEGLIGENCE OR OTHER TORTIOUS ACTION, ARISING OUT OF +.\ OR IN CONNECTION WITH THE USE OR PERFORMANCE OF THIS SOFTWARE. +.\ +.Dd $Mdocdate$ +.Dt USBD_OPEN_PIPE 9 +.Os +.Sh NAME +.Nm usbd_open_pipe , usbd_open_pipe_intr +.Nd create USB pipe +.Sh SYNOPSIS +.In dev/usb/usb.h +.In dev/usb/usbdi.h +.Ft usbd_status +.Fn usbd_open_pipe struct usbd_interface *iface u_int8_t address u_int8_t flags struct usbd_pipe **pipe +.Ft usbd_status +.Fn usbd_open_pipe_intr struct usbd_interface *iface u_int8_t address u_int8_t flags struct usbd_pipe **pipe void *priv void *buffer u_int32_t len usbd_callback cb int ival +.Sh DESCRIPTION +The +.Fn
PATCH: iked SA cleanup on shutdown
Hi folks,
this patch makes iked clean its SAs on shutdown: for each existing IKE
SA, all of their Child SAs will be removed from the kernel, and a IKE
DELETE notification payload will be sent to the peer.
Comments ?
Cheers,
--
Vincent / dermiste
Index: iked.h
===
RCS file: /cvs/src/sbin/iked/iked.h,v
retrieving revision 1.84
diff -u -p -r1.84 iked.h
--- iked.h 26 Mar 2015 19:52:35 - 1.84
+++ iked.h 2 May 2015 17:11:34 -
@@ -549,7 +549,7 @@ struct privsep_proc {
const char *p_chroot;
struct privsep *p_ps;
struct iked *p_env;
- void(*p_shutdown)(void);
+ void(*p_shutdown)(struct privsep_proc *);
u_intp_instance;
};
@@ -744,6 +744,7 @@ pid_tikev1(struct privsep *, struct pr
/* ikev2.c */
pid_t ikev2(struct privsep *, struct privsep_proc *);
+voidikev2_shutdown(struct privsep_proc *);
voidikev2_recv(struct iked *, struct iked_message *);
voidikev2_init_ike_sa(struct iked *, void *);
int ikev2_sa_negotiate(struct iked_proposals *, struct iked_proposals *,
Index: ikev2.c
===
RCS file: /cvs/src/sbin/iked/ikev2.c,v
retrieving revision 1.120
diff -u -p -r1.120 ikev2.c
--- ikev2.c 26 Mar 2015 19:52:35 - 1.120
+++ ikev2.c 2 May 2015 17:11:39 -
@@ -136,7 +136,20 @@ static struct privsep_proc procs[] = {
pid_t
ikev2(struct privsep *ps, struct privsep_proc *p)
{
+ p-p_shutdown = ikev2_shutdown;
return (proc_run(ps, p, procs, nitems(procs), NULL, NULL));
+}
+
+void
+ikev2_shutdown(struct privsep_proc *p)
+{
+ struct iked *env = p-p_env;
+ struct iked_sa *sa, *tmpsa;
+
+ RB_FOREACH_SAFE(sa, iked_sas, env-sc_sas,tmpsa) {
+ ikev2_ikesa_delete(env, sa, sa-sa_hdr.sh_initiator);
+ sa_free(env, sa);
+ }
}
int
Index: proc.c
===
RCS file: /cvs/src/sbin/iked/proc.c,v
retrieving revision 1.22
diff -u -p -r1.22 proc.c
--- proc.c 16 Jan 2015 06:39:58 - 1.22
+++ proc.c 2 May 2015 17:11:39 -
@@ -297,7 +297,7 @@ proc_shutdown(struct privsep_proc *p)
control_cleanup(ps-ps_csock);
if (p-p_shutdown != NULL)
- (*p-p_shutdown)();
+ (*p-p_shutdown)(p);
proc_close(ps);
PATCH: bring crypto(9) up to speed with crypto/cryptodev.h
Hi folks,
crypto(9) describes functions and constants that are not part of
crypto/cryptodev.h anymore (see 1.58 - 1.60), this patch fixes that.
Cheers,
--
Vincent / dermiste
Index: crypto.9
===
RCS file: /cvs/src/share/man/man9/crypto.9,v
retrieving revision 1.37
diff -u -p -r1.37 crypto.9
--- crypto.920 Aug 2014 11:23:42 - 1.37
+++ crypto.92 May 2015 20:02:31 -
@@ -28,21 +28,15 @@
.Ft int
.Fn crypto_register u_int32_t int * int (*)(u_int32_t *, struct cryptoini
*) int (*)(u_int64_t) int (*)(struct cryptop *)
.Ft int
-.Fn crypto_kregister u_int32_t int * int (*)(struct cryptkop *)
-.Ft int
.Fn crypto_unregister u_int32_t int
.Ft void
.Fn crypto_done struct cryptop *
-.Ft void
-.Fn crypto_kdone struct cryptkop *
.Ft int
.Fn crypto_newsession u_int64_t * struct cryptoini * int
.Ft int
.Fn crypto_freesession u_int64_t
.Ft int
.Fn crypto_dispatch struct cryptop *
-.Ft int
-.Fn crypto_kdispatch struct cryptkop *
.Ft struct cryptop *
.Fn crypto_getreq int
.Ft void
@@ -84,23 +78,6 @@ struct cryptop {
caddr_tcrp_mac;
};
-struct crparam {
-caddr_t crp_p;
-u_int crp_nbits;
-};
-
-#define CRK_MAXPARAM8
-
-struct cryptkop {
-u_int krp_op; /* ie. CRK_MOD_EXP or other */
-u_int krp_status; /* return status */
-u_shortkrp_iparams;/* # of input parameters */
-u_shortkrp_oparams;/* # of output parameters */
- u_int32_t krp_hid;
-struct crparam krp_param[CRK_MAXPARAM]; /* kvm */
-int (*krp_callback)(struct cryptkop *);
-struct cryptkop *krp_next;
-};
.Ed
.Sh DESCRIPTION
.Nm
@@ -119,11 +96,6 @@ descriptors that instruct the framework
with it) of the operations that should be applied on the data (more
than one cryptographic operation can be requested).
.Pp
-Keying operations are supported as well.
-Unlike the symmetric operators described above,
-these sessionless commands perform mathematical operations using
-input and output parameters.
-.Pp
Since the consumers may not be associated with a process, drivers may
not use
.Xr tsleep 9 .
@@ -168,8 +140,6 @@ CRYPTO_CAST_CBC
CRYPTO_MD5_HMAC
CRYPTO_SHA1_HMAC
CRYPTO_RIPEMD160_HMAC
-CRYPTO_MD5_KPDK
-CRYPTO_SHA1_KPDK
CRYPTO_AES_CBC
CRYPTO_AES_CTR
CRYPTO_AES_XTS
@@ -391,37 +361,11 @@ callback routine to do the necessary cle
opaque field in the
.Fa cryptop
structure.
-.Pp
-.Fn crypto_kdispatch
-is called to perform a keying operation.
-The various fields in the
-.Fa cryptkop
-structure are:
-.Bl -tag -width crp_alloctype
-.It Fa krp_op
-Operation code, such as CRK_MOD_EXP.
-.It Fa krp_status
-Return code.
-This errno-style variable indicates whether there were lower level reasons
-for operation failure.
-.It Fa krp_iparams
-Number of input parameters to the specified operation.
-Note that each operation has a (typically hardwired) number of such parameters.
-.It Fa krp_oparams
-Number of output parameters from the specified operation.
-Note that each operation has a (typically hardwired) number of such parameters.
-.It Fa krp_kvp
-An array of kernel memory blocks containing the parameters.
-.It Fa krp_hid
-Identifier specifying which low-level driver is being used.
-.It Fa krp_callback
-Callback called on completion of a keying operation.
.El
.Sh DRIVER-SIDE API
The
.Fn crypto_get_driverid ,
.Fn crypto_register ,
-.Fn crypto_kregister ,
.Fn crypto_unregister ,
and
.Fn crypto_done
@@ -465,7 +409,6 @@ The calling convention for the three dri
int (*newsession) (u_int32_t *, struct cryptoini *);
int (*freesession) (u_int64_t);
int (*process) (struct cryptop *);
-int (*kprocess) (struct cryptkop *);
.Ed
.Pp
On invocation, the first argument to
@@ -501,24 +444,8 @@ routine should invoke
.Fn crypto_done .
Session migration may be performed, as mentioned previously.
.Pp
-The
-.Fn kprocess
-routine is invoked with a request to perform crypto key processing.
-This routine must not block, but should queue the request and return
-immediately.
-Upon processing the request, the callback routine should be invoked.
-In case of error, the error indication must be placed in the
-.Fa krp_status
-field of the
-.Fa cryptkop
-structure.
-When the request is completed, or an error is detected, the
-.Fn kprocess
-routine should invoke
-.Fn crypto_kdone .
.Sh RETURN VALUES
.Fn crypto_register ,
-.Fn crypto_kregister ,
.Fn crypto_unregister ,
.Fn crypto_newsession ,
and
Re: bridge(4) and ether_input_mbuf()
Applied.
I don’t see any regressions so far.
I use bridge+vether.
//mxb
On 28 apr 2015, at 23:06, Martin Pieuchot m...@openbsd.org wrote:
On 21/04/15(Tue) 12:35, Martin Pieuchot wrote:
This diff adds the necessary glue to bridge(4) to be able to convert
other pseudo-drivers to if_input(). This will also help bridge(4)'s
own conversion.
Since bridge_input() already returns a mbuf, I believe this change is
less error prone than the carp(4) one. But I appreciate reviews,
tests and oks.
Anybody?
Index: net/bridgestp.c
===
RCS file: /cvs/src/sys/net/bridgestp.c,v
retrieving revision 1.52
diff -u -p -r1.52 bridgestp.c
--- net/bridgestp.c 14 Mar 2015 03:38:51 - 1.52
+++ net/bridgestp.c 20 Apr 2015 11:35:56 -
@@ -596,6 +596,9 @@ bstp_input(struct bstp_state *bs, struct
len = ntohs(eh-ether_type);
if (len sizeof(tpdu))
goto out;
+
+m_adj(m, ETHER_HDR_LEN);
+
if (m-m_pkthdr.len len)
m_adj(m, len - m-m_pkthdr.len);
if ((m = m_pullup(m, sizeof(tpdu))) == NULL)
Index: net/if_bridge.c
===
RCS file: /cvs/src/sys/net/if_bridge.c,v
retrieving revision 1.235
diff -u -p -r1.235 if_bridge.c
--- net/if_bridge.c 17 Apr 2015 11:04:01 - 1.235
+++ net/if_bridge.c 20 Apr 2015 11:55:38 -
@@ -115,10 +115,9 @@ voidbridge_broadcast(struct bridge_soft
struct ether_header *, struct mbuf *);
void bridge_localbroadcast(struct bridge_softc *, struct ifnet *,
struct ether_header *, struct mbuf *);
-voidbridge_span(struct bridge_softc *, struct ether_header *,
-struct mbuf *);
+voidbridge_span(struct bridge_softc *, struct mbuf *);
struct mbuf *bridge_dispatch(struct bridge_iflist *, struct ifnet *,
-struct ether_header *, struct mbuf *);
+ struct mbuf *);
void bridge_stop(struct bridge_softc *);
void bridge_init(struct bridge_softc *);
int bridge_bifconf(struct bridge_softc *, struct ifbifconf *);
@@ -180,6 +179,7 @@ int
bridge_clone_create(struct if_clone *ifc, int unit)
{
struct bridge_softc *sc;
+struct ifih *bridge_ifih;
struct ifnet *ifp;
int i, s;
@@ -187,8 +187,15 @@ bridge_clone_create(struct if_clone *ifc
if (!sc)
return (ENOMEM);
+bridge_ifih = malloc(sizeof(*bridge_ifih), M_DEVBUF, M_NOWAIT);
+if (bridge_ifih == NULL) {
+free(sc, M_DEVBUF, 0);
+return (ENOMEM);
+}
+
sc-sc_stp = bstp_create(sc-sc_if);
if (!sc-sc_stp) {
+free(bridge_ifih, M_DEVBUF, sizeof(*bridge_ifih));
free(sc, M_DEVBUF, 0);
return (ENOMEM);
}
@@ -222,6 +229,9 @@ bridge_clone_create(struct if_clone *ifc
DLT_EN10MB, ETHER_HDR_LEN);
#endif
+bridge_ifih-ifih_input = ether_input;
+SLIST_INSERT_HEAD(ifp-if_inputs, bridge_ifih, ifih_next);
+
s = splnet();
LIST_INSERT_HEAD(bridge_list, sc, sc_list);
splx(s);
@@ -234,6 +244,7 @@ bridge_clone_destroy(struct ifnet *ifp)
{
struct bridge_softc *sc = ifp-if_softc;
struct bridge_iflist *bif;
+struct ifih *bridge_ifih;
int s;
bridge_stop(sc);
@@ -250,6 +261,17 @@ bridge_clone_destroy(struct ifnet *ifp)
splx(s);
bstp_destroy(sc-sc_stp);
+
+/* Undo pseudo-driver changes. */
+if_deactivate(ifp);
+
+bridge_ifih = SLIST_FIRST(ifp-if_inputs);
+SLIST_REMOVE_HEAD(ifp-if_inputs, ifih_next);
+
+KASSERT(SLIST_EMPTY(ifp-if_inputs));
+
+free(bridge_ifih, M_DEVBUF, sizeof(*bridge_ifih));
+
if_detach(ifp);
free(sc, M_DEVBUF, 0);
@@ -990,7 +1012,7 @@ bridge_output(struct ifnet *ifp, struct
struct mbuf *mc;
int used = 0;
-bridge_span(sc, NULL, m);
+bridge_span(sc, m);
TAILQ_FOREACH(p, sc-sc_iflist, next) {
dst_if = p-ifp;
@@ -1066,7 +1088,7 @@ sendunicast:
(sa = bridge_tunneltag(m, dst_p-brt_tunnel.sa.sa_family)) != NULL)
memcpy(sa, dst_p-brt_tunnel.sa, dst_p-brt_tunnel.sa.sa_len);
-bridge_span(sc, NULL, m);
+bridge_span(sc, m);
if ((dst_if-if_flags IFF_RUNNING) == 0) {
m_freem(m);
return (ENETDOWN);
@@ -1282,12 +1304,13 @@ bridgeintr_frame(struct bridge_softc *sc
* not for us, and schedule an interrupt.
*/
struct mbuf *
-bridge_input(struct ifnet *ifp, struct ether_header *eh, struct mbuf *m)
+bridge_input(struct ifnet *ifp, struct ether_header *eh0, struct mbuf *m)
{
struct bridge_softc *sc;
struct bridge_iflist *ifl;
+struct ether_header *eh;
#if NVLAN 0
-uint16_t etype = ntohs(eh-ether_type);
+uint16_t etype = ntohs(eh0-ether_type);
#endif /* NVLAN 0 */
/*
@@ -1306,15 +1329,20 @@ bridge_input(struct ifnet *ifp, struct e
if
Re: [patch] rtl8188eu support for urtwn(4)
Just wanted to report that this works with my TL-WN723N v3.0. With both
patches applied the adapter is able to saturate my DSL connection.
Brendan MacDonell
On Sun, Apr 26, 2015 at 4:46 PM, Mikhail mp39...@gmail.com wrote:
On 21:22 26-Apr 2015 Mikhail wrote:
On 20:20 26-Apr 2015 Stefan Sperling wrote:
On Sun, Apr 26, 2015 at 01:31:17PM +0200, Stefan Sperling wrote:
On Sun, Apr 19, 2015 at 11:48:32PM +0300, Mikhail wrote:
Bellow new version of the patch with above things fixed, also I've
fixed
detection of ETV chip in urtwn_attach(), nothing else is changed.
I'm seeing very low data transmission rates with your patch and a
TP-Link TL-WN725N device. In both 11b and 11g mode, the data rate
remains very low (less than 100Kbit/s). A different urtwn(4) device
(with 8188CUS chip) has much better throughput.
Are you seeing this, too?
The chunk below is wrong for OpenBSD since it sets the intitial transmit
rate to an 11n rate. 0x13 corresponds to the MCS7 11n rate,
see linux/drivers/net/wireless/rtlwifi/rtl8188ee/def.h enum
rtl_desc92c_rate.
The value 11 corresponds to OFDM 54Mbit which is fine for OpenBSD.
We only support 11a/b/g at present.
--- sys/dev/usb/if_urtwn.c 14 Mar 2015 03:38:49 - 1.43
+++ sys/dev/usb/if_urtwn.c 19 Apr 2015 20:27:41 -
@@ -1813,7 +2011,10 @@ urtwn_tx(struct urtwn_softc *sc, struct
txd-txdw4 |= htole32(SM(R92C_TXDW4_RTSRATE, 8));
txd-txdw5 |= htole32(0x0001ff00);
/* Send data at OFDM54. */
- txd-txdw5 |= htole32(SM(R92C_TXDW5_DATARATE, 11));
+ if (sc-chip URTWN_CHIP_88E)
+ txd-txdw5 |= htole32(0x13 0x3f);
+ else
+ txd-txdw5 |= htole32(SM(R92C_TXDW5_DATARATE, 11));
} else {
txd-txdw1 |= htole32(
Reverting this change doesn't fix the transmit speed problem,
unfortunately.
I wonder if we're making some mistake while setting up the TX descriptor?
There are several differences in the TX descriptors of 88E vs 92C.
For example, 88E has third antenna C available.
Hello, in urtwn_init(), in part:
if (sc-chip URTWN_CHIP_88E)
urtwn_write_1(sc, R92C_RXDMA_AGG_PG_TH + 1, 4);
else
urtwn_write_1(sc, R92C_USB_DMA_AGG_TO, 4);
comment first 3 lines. It fixes speed problem for me, but I need to
understand the issue further, before proposing any solution.
The issue isn't in those lines, but a little bit higher - the driver
enables usb and dma aggregations, but native linux implementation
enables only dma and disables usb one.
I've submitted bug report to FreeBSD[1] with a patch, which I see as a
proper solution:
urtwn_write_1(sc, R92C_USB_SPECIAL_OPTION,
urtwn_read_1(sc, R92C_USB_SPECIAL_OPTION) |
- R92C_USB_SPECIAL_OPTION_AGG_EN);
+ (sc-chip URTWN_CHIP_88E ?
+ ~R92C_USB_SPECIAL_OPTION_AGG_EN :
+R92C_USB_SPECIAL_OPTION_AGG_EN));
I'd suggest to wait some time for feedback. Testing is welcome, of
course. Thank you for pointing this out and review in general.
[1] - https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=199718
Re: [ping] dump -U by default
On Wed, Apr 15, 2015 at 10:14 AM, Philip Guenther guent...@gmail.com wrote: On Wed, Apr 15, 2015 at 5:48 AM, Manuel Giraud man...@ledu-giraud.fr wrote: Here is a patch that eliminate the -U flag for dump and make usage of DUID in /etc/dumpdates the default. It also correct old style entries so nothing has to be done for the admin :) Yeah, I've started using this and it looks good so far. Just a couple corner cases to verify tonight and presuming it looks good I'll commit tonight. Heh, tonight, rght... So the diff itself does what I expect, but running with it has revealed that the -w and -W options need work. Consider this output: : morgaine; dump -w Dump these file systems: /dev/rsd0i(/usr/src) Last dump: Level 0, Date Wed Apr 8 11:14 /dev/rsd0k( /home) Last dump: Level 4, Date Wed Mar 25 00:33 : morgaine; dump -W Last dump(s) done (Dump '' file systems): /dev/rsd0f( /usr) Last dump: Level 0, Date Thu Mar 13 10:29 /dev/rsd0i(/usr/src) Last dump: Level 0, Date Wed Apr 8 11:14 /dev/rsd0k( /home) Last dump: Level 4, Date Wed Mar 25 00:33 a7df1ec64e79a49c.i( ) Last dump: Level 2, Date Wed Apr 15 09:56 a7df1ec64e79a49c.k( ) Last dump: Level 6, Date Sat May 2 18:32 : morgaine; egrep 'src|home' /etc/fstab /dev/sd0k /homeffsro,nodev,softdep 6 2 /dev/sd0i /usr/src ffsro,nodev,nosuid,softdep 6 2 : morgaine; Yes, DUID a7df...49c is sd0, so the dump -w output is incorrect: last dump of /home was just minutes ago, recorded under the DUID. Yes, the output is correct once I change /etc/fstab to use the DUID, but if we're going to automatically switch to DUIDs for /etc/dumpdates then we should match them up automatically too. So I'll commit your diff; you wanna switch at doing the matching for -w/-W ? Philip Guenther
