El Gerente de Ventas como Administrador, Vendedor y Lí
El Gerente de Ventas como Administrador, Vendedor y Líder Panama 08 de Agosto, 2012 Los Gerentes de Ventas tienen en sus manos uno de los procesos más importantes y fundamentales para el ÉXITO o FRACASO de las empresas, por lo que constantemente se ven obligados y presionados ante las situaciones adversas del mercado, las reacciones de la competencia y los clientes, debiendo desarrollar estrategias efectivas que permitan a sus empresas posicionar sus productos y/o servicios con altos niveles de rentabilidad y ventajas competitivas duraderas. Este programa le ofrece un panorama claro y efectivo de las medidas inmediatas que debe considerar, incluyendo: - Métodos eficaces para administrar su equipo de VENTAS centrado en resultados. - Análisis de casos reales - ¿Por qué fracasan las fuerzas de ventas? - ¿Cómo identificar y vencer los obstáculos que le impiden obtener mejores resultados? Reciba en este momento el folleto completo! Únicamente responda con su Nombre, Puesto, Empresa y Teléfono, o Comuníquese al (507) 279-1083 / 279-0258 / 279-0887 en donde con gusto le atenderé. Reciba un muy cordial saludo! Lic. Ericka Lopez Líder de Proyectos Para des suscribirse de estas invitaciones, solo responda este correo con el Asunto no-enviar y automáticamente quedará fuera de nuestras listas. Este correo ha sido enviado a: tech@openbsd.org
Re: ACPI WMI project, need help
On Mon, Jul 30, 2012 at 09:52:18PM +0400, Alexander Polakov wrote: > Hi, > > I started working on porting ACPI WMI (WMI stands for Windows Management > Instrumentation, it's ACPI extension by Microsoft) driver from NetBSD hoping > it will help me with my HP Compaq 6910p problem [1]. > > Currently, device attaches, and I can do some simple stuff, like dumping > its guids table (and attach dumb acpihp on top of it). > > acpiwmi0 at acpi0: ACPI WMI Interface > acpiwmi0: {5FB7F034-2C63-45E9-BE91-3D44E2C707E4} oid 4141 count 01 flags 02 > acpiwmi0: {95F24279-4D7B-4334-9387-ACCDC67EF61C} oid 0080 count 01 flags 08 > acpiwmi0: {2B814318-4BE8-4707-9D84-A190A859B5D0} oid 00A0 count 01 flags 08 > acpiwmi0: {05901221-D566-11D1-B2F0-00A0C9062910} oid 4241 count 01 flags 00 > acpiwmi0: {1F4C91EB-DC5C-460B-951D-C7CB9B4B8D5E} oid 4142 count 01 flags 02 > acpiwmi0: {2D114B49-2DFB-4130-B8FE-4A3C09E75133} oid 4342 count 35 flags 00 > acpiwmi0: {988D08E3-68F4-4C35-AF3E-6A1B8106F83C} oid 4442 count 14 flags 00 > acpiwmi0: {14EA9746-CE1F-4098-A0E0-7045CB4DA745} oid 4542 count 01 flags 00 > acpiwmi0: {322F2028-0F84-4901-988E-015176049E2D} oid 4642 count 02 flags 00 > acpiwmi0: {8232DE3D-663D-4327-A8F4-E293ADB9BF05} oid 4742 count 00 flags 00 > acpiwmi0: {8F1F6436-9F42-42C8-BADC-0E9424F20C9A} oid 4842 count 00 flags 00 > acpiwmi0: {8F1F6435-9F42-42C8-BADC-0E9424F20C9A} oid 4942 count 00 flags 00 > acpihp0 at acpiwmi0: HP WMI mappings > > What really bothers me here is acpi_wmi_init_ec() function, which claims > to install "address space handler" for the EC space. > > Here it is: > > static void > acpi_wmi_init_ec(struct acpi_wmi_softc *sc) > { > > > rv = AcpiInstallAddressSpaceHandler(sc->sc_node->ad_handle, > ACPI_ADR_SPACE_EC, acpi_wmi_ec_handler, NULL, sc); > > if (ACPI_FAILURE(rv)) > sc->sc_ecdev = NULL; > } > > You can see code for AcpiInstallAddressSpaceHandler() here [2]. > > The handler itself looks like this: > > /* > * Handler for EC regions, which may be embedded in WMI. > */ > static int > acpi_wmi_ec_handler(uint32_t func, ACPI_PHYSICAL_ADDRESS addr, > uint32_t width, ACPI_INTEGER *val, void *setup, void *aux) > { > struct acpi_wmi_softc *sc = aux; > > if (aux == NULL || val == NULL) > return AE_BAD_PARAMETER; > > if (addr > 0xFF || width % 8 != 0) > return AE_BAD_ADDRESS; > > switch (func) { > > case ACPI_READ: > (void)acpiec_bus_read(sc->sc_ecdev, addr, val, width); > break; > > case ACPI_WRITE: > (void)acpiec_bus_write(sc->sc_ecdev, addr, *val, width); > break; > > default: > return AE_BAD_PARAMETER; > } > > return AE_OK; > } > > My problem is that I can't find something similar in our ACPI stack. > NetBSD installs address space handler in their EC driver too, but > OpenBSD doesn't do this. Can I safely ignore this piece of code, or > is it crucial for properly operating the device? > > Begging for a helping hand from ACPI guru. > > [1] > http://old.nabble.com/HP-6910p%3A-keyboard---touchpad-not-working-p34156209.html > [2] > http://grok.x12.su/source/xref/netbsd/sys/external/intel-public/acpica/dist/events/evxfregn.c#130 > It's likely important, so you should probably look for a way to implement the missing parts. -ml
Re: use time_uptime for various pf expirations
On 30.7.2012. 12:32, Florian Obser wrote: > On Mon, Jul 30, 2012 at 12:07:15AM +0200, Hrvoje Popovski wrote: >> On 29.7.2012. 18:09, Mike Belopuhov wrote: >>> On Sun, Jul 29, 2012 at 5:47 PM, Hrvoje Popovski wrote: Hello, i have tested your patches with torrent box behind 2 firewalls (nat, carp,pfsync). One firewall is patched and second box isn't. Both of them quite often export flows with duration of 429496* >>> >>> is it possible that these flows are coming from the unpatched box? >>> you can compare creatorid value to the hostid that is prited by >>> pfctl -vsi. >>> >> >> Hello, >> >> now with only one patched firewall, second firewall is halted, i'm still >> having flows with 4294*. >> > > There are 3 calls to pf_unlink_state in pf.c which leed to pflow (and > some more in if_pfsync.c und pf_ioctl.c). I think my patch fixes the > call in pf_purge_expired_states and you are seeing the call in > pf_test_state_tcp. > > Benno pointed out that we can skip the timeout dance in if_pflow.c > since with my patch st->expire contains time_uptime when the last > package for that state was seen. This is supposed to be on top of my > original patch: > > Index: sys/net/if_pflow.c > === > RCS file: /opt/OpenBSD-CVS/src/sys/net/if_pflow.c,v > retrieving revision 1.20 > diff -u -p -r1.20 if_pflow.c > --- sys/net/if_pflow.c11 Apr 2012 17:42:53 - 1.20 > +++ sys/net/if_pflow.c30 Jul 2012 09:08:43 - > @@ -555,10 +555,8 @@ copy_flow_data(struct pflow_flow *flow1, > > flow1->flow_start = flow2->flow_start = > htonl(st->creation * 1000); > - flow1->flow_finish = flow2->flow_finish = > - htonl((time_uptime - (st->rule.ptr->timeout[st->timeout] ? > - st->rule.ptr->timeout[st->timeout] : > - pf_default_rule.timeout[st->timeout])) * 1000); > + flow1->flow_finish = flow2->flow_finish = htonl(st->expire * 1000); > + > flow1->tcp_flags = flow2->tcp_flags = 0; > flow1->protocol = flow2->protocol = sk->proto; > flow1->tos = flow2->tos = st->rule.ptr->tos; > @@ -582,10 +580,7 @@ copy_flow4_data(struct pflow_flow4 *flow > > flow1->flow_start = flow2->flow_start = > htonl(st->creation * 1000); > - flow1->flow_finish = flow2->flow_finish = > - htonl((time_uptime - (st->rule.ptr->timeout[st->timeout] ? > - st->rule.ptr->timeout[st->timeout] : > - pf_default_rule.timeout[st->timeout])) * 1000); > + flow1->flow_finish = flow2->flow_finish = htonl(st->expire * 1000); > > flow1->protocol = flow2->protocol = sk->proto; > flow1->tos = flow2->tos = st->rule.ptr->tos; > @@ -610,10 +605,7 @@ copy_flow6_data(struct pflow_flow6 *flow > > flow1->flow_start = flow2->flow_start = > htonl(st->creation * 1000); > - flow1->flow_finish = flow2->flow_finish = > - htonl((time_uptime - (st->rule.ptr->timeout[st->timeout] ? > - st->rule.ptr->timeout[st->timeout] : > - pf_default_rule.timeout[st->timeout])) * 1000); > + flow1->flow_finish = flow2->flow_finish = htonl(st->expire * 1000); > > flow1->protocol = flow2->protocol = sk->proto; > flow1->tos = flow2->tos = st->rule.ptr->tos; > > Hello, I have applied your new patch on top of old one and I still see 4294* flow duration. I have tcpdumped 5 min netflow traffic on collector and have same 5 min netflow data if you are interested. http://kosjenka.srce.hr/~hrvoje/netflow.pcap http://kosjenka.srce.hr/~hrvoje/netflow.txt
ACPI WMI project, need help
Hi, I started working on porting ACPI WMI (WMI stands for Windows Management Instrumentation, it's ACPI extension by Microsoft) driver from NetBSD hoping it will help me with my HP Compaq 6910p problem [1]. Currently, device attaches, and I can do some simple stuff, like dumping its guids table (and attach dumb acpihp on top of it). acpiwmi0 at acpi0: ACPI WMI Interface acpiwmi0: {5FB7F034-2C63-45E9-BE91-3D44E2C707E4} oid 4141 count 01 flags 02 acpiwmi0: {95F24279-4D7B-4334-9387-ACCDC67EF61C} oid 0080 count 01 flags 08 acpiwmi0: {2B814318-4BE8-4707-9D84-A190A859B5D0} oid 00A0 count 01 flags 08 acpiwmi0: {05901221-D566-11D1-B2F0-00A0C9062910} oid 4241 count 01 flags 00 acpiwmi0: {1F4C91EB-DC5C-460B-951D-C7CB9B4B8D5E} oid 4142 count 01 flags 02 acpiwmi0: {2D114B49-2DFB-4130-B8FE-4A3C09E75133} oid 4342 count 35 flags 00 acpiwmi0: {988D08E3-68F4-4C35-AF3E-6A1B8106F83C} oid 4442 count 14 flags 00 acpiwmi0: {14EA9746-CE1F-4098-A0E0-7045CB4DA745} oid 4542 count 01 flags 00 acpiwmi0: {322F2028-0F84-4901-988E-015176049E2D} oid 4642 count 02 flags 00 acpiwmi0: {8232DE3D-663D-4327-A8F4-E293ADB9BF05} oid 4742 count 00 flags 00 acpiwmi0: {8F1F6436-9F42-42C8-BADC-0E9424F20C9A} oid 4842 count 00 flags 00 acpiwmi0: {8F1F6435-9F42-42C8-BADC-0E9424F20C9A} oid 4942 count 00 flags 00 acpihp0 at acpiwmi0: HP WMI mappings What really bothers me here is acpi_wmi_init_ec() function, which claims to install "address space handler" for the EC space. Here it is: static void acpi_wmi_init_ec(struct acpi_wmi_softc *sc) { rv = AcpiInstallAddressSpaceHandler(sc->sc_node->ad_handle, ACPI_ADR_SPACE_EC, acpi_wmi_ec_handler, NULL, sc); if (ACPI_FAILURE(rv)) sc->sc_ecdev = NULL; } You can see code for AcpiInstallAddressSpaceHandler() here [2]. The handler itself looks like this: /* * Handler for EC regions, which may be embedded in WMI. */ static int acpi_wmi_ec_handler(uint32_t func, ACPI_PHYSICAL_ADDRESS addr, uint32_t width, ACPI_INTEGER *val, void *setup, void *aux) { struct acpi_wmi_softc *sc = aux; if (aux == NULL || val == NULL) return AE_BAD_PARAMETER; if (addr > 0xFF || width % 8 != 0) return AE_BAD_ADDRESS; switch (func) { case ACPI_READ: (void)acpiec_bus_read(sc->sc_ecdev, addr, val, width); break; case ACPI_WRITE: (void)acpiec_bus_write(sc->sc_ecdev, addr, *val, width); break; default: return AE_BAD_PARAMETER; } return AE_OK; } My problem is that I can't find something similar in our ACPI stack. NetBSD installs address space handler in their EC driver too, but OpenBSD doesn't do this. Can I safely ignore this piece of code, or is it crucial for properly operating the device? Begging for a helping hand from ACPI guru. [1] http://old.nabble.com/HP-6910p%3A-keyboard---touchpad-not-working-p34156209.html [2] http://grok.x12.su/source/xref/netbsd/sys/external/intel-public/acpica/dist/events/evxfregn.c#130
Re: use time_uptime for various pf expirations
On Mon, Jul 30, 2012 at 12:07:15AM +0200, Hrvoje Popovski wrote: > On 29.7.2012. 18:09, Mike Belopuhov wrote: > > On Sun, Jul 29, 2012 at 5:47 PM, Hrvoje Popovski wrote: > >> > >> Hello, > >> > >> i have tested your patches with torrent box behind 2 firewalls (nat, > >> carp,pfsync). One firewall is patched and second box isn't. Both of them > >> quite often export flows with duration of 429496* > >> > > > > is it possible that these flows are coming from the unpatched box? > > you can compare creatorid value to the hostid that is prited by > > pfctl -vsi. > > > > Hello, > > now with only one patched firewall, second firewall is halted, i'm still > having flows with 4294*. > There are 3 calls to pf_unlink_state in pf.c which leed to pflow (and some more in if_pfsync.c und pf_ioctl.c). I think my patch fixes the call in pf_purge_expired_states and you are seeing the call in pf_test_state_tcp. Benno pointed out that we can skip the timeout dance in if_pflow.c since with my patch st->expire contains time_uptime when the last package for that state was seen. This is supposed to be on top of my original patch: Index: sys/net/if_pflow.c === RCS file: /opt/OpenBSD-CVS/src/sys/net/if_pflow.c,v retrieving revision 1.20 diff -u -p -r1.20 if_pflow.c --- sys/net/if_pflow.c 11 Apr 2012 17:42:53 - 1.20 +++ sys/net/if_pflow.c 30 Jul 2012 09:08:43 - @@ -555,10 +555,8 @@ copy_flow_data(struct pflow_flow *flow1, flow1->flow_start = flow2->flow_start = htonl(st->creation * 1000); - flow1->flow_finish = flow2->flow_finish = - htonl((time_uptime - (st->rule.ptr->timeout[st->timeout] ? - st->rule.ptr->timeout[st->timeout] : - pf_default_rule.timeout[st->timeout])) * 1000); + flow1->flow_finish = flow2->flow_finish = htonl(st->expire * 1000); + flow1->tcp_flags = flow2->tcp_flags = 0; flow1->protocol = flow2->protocol = sk->proto; flow1->tos = flow2->tos = st->rule.ptr->tos; @@ -582,10 +580,7 @@ copy_flow4_data(struct pflow_flow4 *flow flow1->flow_start = flow2->flow_start = htonl(st->creation * 1000); - flow1->flow_finish = flow2->flow_finish = - htonl((time_uptime - (st->rule.ptr->timeout[st->timeout] ? - st->rule.ptr->timeout[st->timeout] : - pf_default_rule.timeout[st->timeout])) * 1000); + flow1->flow_finish = flow2->flow_finish = htonl(st->expire * 1000); flow1->protocol = flow2->protocol = sk->proto; flow1->tos = flow2->tos = st->rule.ptr->tos; @@ -610,10 +605,7 @@ copy_flow6_data(struct pflow_flow6 *flow flow1->flow_start = flow2->flow_start = htonl(st->creation * 1000); - flow1->flow_finish = flow2->flow_finish = - htonl((time_uptime - (st->rule.ptr->timeout[st->timeout] ? - st->rule.ptr->timeout[st->timeout] : - pf_default_rule.timeout[st->timeout])) * 1000); + flow1->flow_finish = flow2->flow_finish = htonl(st->expire * 1000); flow1->protocol = flow2->protocol = sk->proto; flow1->tos = flow2->tos = st->rule.ptr->tos; -- I'm not entirely sure you are real.
Re: ftp mput recursiv upload diff for testing
Hopefully the final version. Index: cmds.c === RCS file: /cvs/src/usr.bin/ftp/cmds.c,v retrieving revision 1.70 diff -u -p -r1.70 cmds.c --- cmds.c 5 May 2009 19:35:30 - 1.70 +++ cmds.c 30 Jul 2012 07:58:16 - @@ -231,15 +231,32 @@ mput(int argc, char *argv[]) extern int optind, optreset; int ch, i, restartit = 0; sig_t oldintr; - char *cmd, *tp; + char *cmd, *tp, *xargv[] = { argv[0], NULL, NULL }; + const char *errstr; + static int depth = 0, max_depth = 0; optind = optreset = 1; - while ((ch = getopt(argc, argv, "c")) != -1) { + if (depth) + depth++; + + while ((ch = getopt(argc, argv, "cd:r")) != -1) { switch(ch) { case 'c': restartit = 1; break; + case 'd': + max_depth = strtonum(optarg, 0, INT_MAX, &errstr); + if (errstr != NULL) { + fprintf(ttyout, "bad depth value, %s: %s\n", + errstr, optarg); + code = -1; + return; + } + break; + case 'r': + depth = 1; + break; default: goto usage; } @@ -247,7 +264,8 @@ mput(int argc, char *argv[]) if (argc - optind < 1 && !another(&argc, &argv, "local-files")) { usage: - fprintf(ttyout, "usage: %s [-c] local-files\n", argv[0]); + fprintf(ttyout, "usage: %s [-cr] [-d depth] local-files\n", + argv[0]); code = -1; return; } @@ -318,11 +336,13 @@ usage: mflag = 0; return; } + for (i = 1; i < argc; i++) { char **cpp; glob_t gl; int flags; + /* Copy files without word expansion */ if (!doglob) { if (mflag && confirm(argv[0], argv[i])) { tp = (ntflag) ? dotrans(argv[i]) : argv[i]; @@ -348,6 +368,7 @@ usage: continue; } + /* expanding file names */ memset(&gl, 0, sizeof(gl)); flags = GLOB_BRACE|GLOB_NOCHECK|GLOB_QUOTE|GLOB_TILDE; if (glob(argv[i], flags, NULL, &gl) || gl.gl_pathc == 0) { @@ -355,33 +376,89 @@ usage: globfree(&gl); continue; } + + /* traverse all expanded file names */ for (cpp = gl.gl_pathv; cpp && *cpp != NULL; cpp++) { - if (mflag && confirm(argv[0], *cpp)) { - tp = (ntflag) ? dotrans(*cpp) : *cpp; - tp = (mapflag) ? domap(tp) : tp; - if (restartit == 1) { - off_t ret; + struct stat filestat; - if (curtype != type) - changetype(type, 0); - ret = remotesize(tp, 0); - restart_point = (ret < 0) ? 0 : ret; - } - cmd = restartit ? "APPE" : ((sunique) ? - "STOU" : "STOR"); - sendrequest(cmd, *cpp, tp, - *cpp != tp || !interactive); - restart_point = 0; - if (!mflag && fromatty) { - if (confirm(argv[0], NULL)) - mflag = 1; + if (!mflag) + continue; + if (stat(*cpp, &filestat) != 0) { + warn("local: %s", *cpp); + continue; + } + if (S_ISDIR(filestat.st_mode) && depth == max_depth) + continue; + if (!confirm(argv[0], *cpp)) + continue; + + /* +* If file is a directory then create a new one +* at the remote machine. +*/ + if (S_ISDIR(filestat.st_mode)) { + xargv[1] = *cpp; + makedir(2, xargv); + cd(2, xargv); + if (dirchange != 1) { + warnx("remote: %s", *