Re: patch - RFC 4638 increased MTU support for pppoe(8) w/ ppp(8)
On 2012/01/31 23:53, Ben Gould wrote:
> I couldn't get the pppoe server to work on -current, rebuilt -current
> yesterday and it now works - user error.
>
> The following works in all the combinations 5.0 client/server
> userland and with -current client/server and with -current pppoe(4).
>
> -- ben
fixed diff (linewrapping and some spaces->tabs and 80-column
formatting in the diff itself), otherwise untested so far.
Index: client.c
===
RCS file: /cvs/src/usr.sbin/pppoe/client.c,v
retrieving revision 1.24
diff -u -p -r1.24 client.c
--- client.c5 Nov 2011 09:20:36 - 1.24
+++ client.c1 Feb 2012 02:34:04 -
@@ -50,6 +50,7 @@
u_int32_t client_cookie;
u_int16_t client_sessionid;
+u_int16_t client_mtu;
int pppfd, client_state;
static int getpackets(int, u_int8_t *, u_int8_t *, struct ether_addr *,
@@ -80,6 +81,7 @@ client_mode(int bfd, u_int8_t *sysname,
pppfd = -1;
client_sessionid = 0x;
client_state = -1;
+ client_mtu = 0;
r = send_padi(bfd, myea, srvname);
if (r <= 0)
@@ -144,13 +146,14 @@ client_mode(int bfd, u_int8_t *sysname,
static int
send_padi(int fd, struct ether_addr *ea, u_int8_t *srv)
{
- struct iovec iov[10];
+ struct iovec iov[12];
struct pppoe_header ph = {
PPPOE_VERTYPE(1, 1),
PPPOE_CODE_PADI, 0, 0
};
- struct pppoe_tag thost, tserv;
+ struct pppoe_tag thost, tserv, tmaxpayload;
u_int16_t etype = htons(ETHERTYPE_PPPOEDISC);
+ u_int16_t maxpayload;
int i = 0;
/* ether_header */
@@ -190,6 +193,22 @@ send_padi(int fd, struct ether_addr *ea,
}
tserv.len = htons(tserv.len);
+ /* ppp-max-payload tag (optional) */
+ if (rfc_4638_mtu > PPPOE_MIN_MTU) {
+ tmaxpayload.type = htons(PPPOE_TAG_PPP_MAX_PAYLOAD);
+ tmaxpayload.len = htons(sizeof(maxpayload));
+ tmaxpayload.val = (u_int8_t*) &maxpayload;
+ maxpayload = htons(rfc_4638_mtu);
+ iov[i].iov_base = &tmaxpayload;
+ iov[i++].iov_len = sizeof(tmaxpayload.len) +
+ sizeof(tmaxpayload.type);
+ iov[i].iov_base = &maxpayload;
+ iov[i++].iov_len = sizeof(maxpayload);
+ ph.len += sizeof(tmaxpayload.len) +
+ sizeof(tmaxpayload.type) + sizeof(maxpayload);
+ }
+
+
ph.len = htons(ph.len);
client_state = STATE_EXPECT_PADO;
@@ -202,9 +221,10 @@ send_padr(int bfd, u_int8_t *srv, struct
struct ether_addr *rmea, struct ether_header *eh,
struct pppoe_header *ph, struct tag_list *tl)
{
- struct iovec iov[12];
+ struct iovec iov[14];
u_int16_t etype = htons(ETHERTYPE_PPPOEDISC);
- struct pppoe_tag hutag, svtag;
+ struct pppoe_tag hutag, svtag, mptag;
+ u_int16_t maxpayload = htons(client_mtu);
struct tag_node *n;
int idx = 0, slen;
@@ -245,6 +265,19 @@ send_padr(int bfd, u_int8_t *srv, struct
iov[idx++].iov_len = slen;
}
+ /* PPP-Max-Payload */
+ if (client_mtu > 0) {
+ mptag.type = htons(PPPOE_TAG_PPP_MAX_PAYLOAD);
+ mptag.len = htons(sizeof(maxpayload));
+ iov[idx].iov_base = &mptag;
+ iov[idx++].iov_len = sizeof(mptag.type) + sizeof(mptag.len);
+ iov[idx].iov_base = &maxpayload;
+ iov[idx++].iov_len = sizeof(maxpayload);
+ ph->len += sizeof(mptag.type) + sizeof(mptag.len) +
+ sizeof(maxpayload);
+ }
+
+
n = tag_lookup(tl, PPPOE_TAG_RELAY_SESSION, 0);
if (n != NULL) {
iov[idx].iov_base = &n->type;
@@ -407,6 +440,18 @@ recv_pado(int bfd, u_int8_t *srv, struct
if (bcmp(n->val, &client_cookie, sizeof(client_cookie)))
goto out;
+ n = tag_lookup(&tl, PPPOE_TAG_PPP_MAX_PAYLOAD, 0);
+ if (n != NULL) {
+ client_mtu = n->val[1] | (n->val[0] << 8);
+ if (client_mtu > rfc_4638_mtu) {
+ client_mtu = rfc_4638_mtu;
+ } else if (client_mtu < PPPOE_MIN_MTU) {
+ client_mtu = PPPOE_MIN_MTU;
+ }
+ } else {
+ client_mtu = 0;
+ }
+
r = 0;
slen = (srv == NULL) ? 0 : strlen((char *)srv);
while ((n = tag_lookup(&tl, PPPOE_TAG_SERVICE_NAME, r)) != NULL) {
@@ -462,6 +507,18 @@ recv_pads(int bfd, u_int8_t *srv, u_int8
goto out;
if (bcmp(n->val, &client_cookie, sizeof(client_cookie)))
goto out;
+
+ n = tag_lookup(&tl, PPPOE_TAG_PPP_MAX_PAYLOAD, 0);
+ if (n != NULL && n->len == sizeof(client_mtu)) {
+ client_mtu = n->val[1] | (n->val[0] << 8);
+ if (client_mtu > rfc_4638_mtu ||
+ client_mtu < PPPOE
login_yubikey manpage missing stuff
Curiosity made me look at login_yubikey and so I looked at its manpage. The synopsis says: login_yubikey [-d] [-s service] user [class] Nowhere was an explanation of -d. Guessing that it was debug I went looking at the source and saw that there was yet another flag unmentioned, to wit, -v. This was following a complete cvs up yesterday followed by all the steps upto and including make release. Perhaps a maestro manpager would like to explain the missing options? You wouldn't want a diff from me for task 8-) *** NOTE *** Please DO NOT CC me. I subscribed to the list. Mail to the sender address that does not originate at the list server is tarpitted. The reply-to: address is provided for those who feel compelled to reply off list. Thankyou. Rod/ --- This life is not the real thing. It is not even in Beta. If it was, then OpenBSD would already have a man page for it.
Re: patch - RFC 4638 increased MTU support for pppoe(8) w/ ppp(8)
I couldn't get the pppoe server to work on -current, rebuilt -current
yesterday and it now works - user error.
The following works in all the combinations 5.0 client/server userland
and with -current client/server and with -current pppoe(4).
-- ben
Index: client.c
===
RCS file: /cvs/src/usr.sbin/pppoe/client.c,v
retrieving revision 1.24
diff -u -p -r1.24 client.c
--- client.c5 Nov 2011 09:20:36 -1.24
+++ client.c30 Jan 2012 22:35:46 -
@@ -50,6 +50,7 @@
u_int32_t client_cookie;
u_int16_t client_sessionid;
+u_int16_t client_mtu;
int pppfd, client_state;
static int getpackets(int, u_int8_t *, u_int8_t *, struct ether_addr *,
@@ -80,6 +81,7 @@ client_mode(int bfd, u_int8_t *sysname,
pppfd = -1;
client_sessionid = 0x;
client_state = -1;
+client_mtu = 0;
r = send_padi(bfd, myea, srvname);
if (r <= 0)
@@ -144,13 +146,14 @@ client_mode(int bfd, u_int8_t *sysname,
static int
send_padi(int fd, struct ether_addr *ea, u_int8_t *srv)
{
-struct iovec iov[10];
+struct iovec iov[12];
struct pppoe_header ph = {
PPPOE_VERTYPE(1, 1),
PPPOE_CODE_PADI, 0, 0
};
-struct pppoe_tag thost, tserv;
+struct pppoe_tag thost, tserv, tmaxpayload;
u_int16_t etype = htons(ETHERTYPE_PPPOEDISC);
+u_int16_t maxpayload;
int i = 0;
/* ether_header */
@@ -190,6 +193,21 @@ send_padi(int fd, struct ether_addr *ea,
}
tserv.len = htons(tserv.len);
+/* ppp-max-payload tag (optional) */
+if (rfc_4638_mtu > PPPOE_MIN_MTU) {
+tmaxpayload.type = htons(PPPOE_TAG_PPP_MAX_PAYLOAD);
+tmaxpayload.len = htons(sizeof(maxpayload));
+tmaxpayload.val = (u_int8_t*) &maxpayload;
+maxpayload = htons(rfc_4638_mtu);
+iov[i].iov_base = &tmaxpayload;
+iov[i++].iov_len = sizeof(tmaxpayload.len) +
sizeof(tmaxpayload.type);
+iov[i].iov_base = &maxpayload;
+iov[i++].iov_len = sizeof(maxpayload);
+ph.len += sizeof(tmaxpayload.len) + sizeof(tmaxpayload.type) +
+sizeof(maxpayload);
+}
+
+
ph.len = htons(ph.len);
client_state = STATE_EXPECT_PADO;
@@ -202,9 +220,10 @@ send_padr(int bfd, u_int8_t *srv, struct
struct ether_addr *rmea, struct ether_header *eh,
struct pppoe_header *ph, struct tag_list *tl)
{
-struct iovec iov[12];
+struct iovec iov[14];
u_int16_t etype = htons(ETHERTYPE_PPPOEDISC);
-struct pppoe_tag hutag, svtag;
+struct pppoe_tag hutag, svtag, mptag;
+u_int16_t maxpayload = htons(client_mtu);
struct tag_node *n;
int idx = 0, slen;
@@ -245,6 +264,18 @@ send_padr(int bfd, u_int8_t *srv, struct
iov[idx++].iov_len = slen;
}
+/* PPP-Max-Payload */
+if (client_mtu > 0) {
+mptag.type = htons(PPPOE_TAG_PPP_MAX_PAYLOAD);
+mptag.len = htons(sizeof(maxpayload));
+iov[idx].iov_base = &mptag;
+iov[idx++].iov_len = sizeof(mptag.type) + sizeof(mptag.len);
+iov[idx].iov_base = &maxpayload;
+iov[idx++].iov_len = sizeof(maxpayload);
+ph->len += sizeof(mptag.type) + sizeof(mptag.len) +
sizeof(maxpayload);
+}
+
+
n = tag_lookup(tl, PPPOE_TAG_RELAY_SESSION, 0);
if (n != NULL) {
iov[idx].iov_base = &n->type;
@@ -407,6 +438,18 @@ recv_pado(int bfd, u_int8_t *srv, struct
if (bcmp(n->val, &client_cookie, sizeof(client_cookie)))
goto out;
+n = tag_lookup(&tl, PPPOE_TAG_PPP_MAX_PAYLOAD, 0);
+if (n != NULL) {
+client_mtu = n->val[1] | (n->val[0] << 8);
+if (client_mtu > rfc_4638_mtu) {
+client_mtu = rfc_4638_mtu;
+} else if (client_mtu < PPPOE_MIN_MTU) {
+client_mtu = PPPOE_MIN_MTU;
+}
+} else {
+client_mtu = 0;
+}
+
r = 0;
slen = (srv == NULL) ? 0 : strlen((char *)srv);
while ((n = tag_lookup(&tl, PPPOE_TAG_SERVICE_NAME, r)) != NULL) {
@@ -462,6 +505,18 @@ recv_pads(int bfd, u_int8_t *srv, u_int8
goto out;
if (bcmp(n->val, &client_cookie, sizeof(client_cookie)))
goto out;
+
+n = tag_lookup(&tl, PPPOE_TAG_PPP_MAX_PAYLOAD, 0);
+if (n != NULL && n->len == sizeof(client_mtu)) {
+client_mtu = n->val[1] | (n->val[0] << 8);
+if (client_mtu > rfc_4638_mtu ||
+client_mtu < PPPOE_MIN_MTU) {
+/* error; fallback */
+client_mtu = 0;
+}
+} else {
+client_mtu = 0;
+}
if (ph->sessionid == 0) {
timer_clr();
Index: common.c
===
RCS file: /cvs/src/usr.sbin/pppoe/common.c,v
retrieving revision 1.13
diff -u -p -r1.13 common.c
--- common.c5 Nov 2011 09:20:36 -1.13
+++ common.c30 Jan 2012 22:35:46 -
@@ -138,7 +138,7 @@ ppp_to_bpf(int bfd, int pppfd, struct et
int r;
if (pktbuf == NULL) {
-pktbuf = (u_int8_t *)malloc(PPPOE_MTU);
+
Re: patch - RFC 4638 increased MTU support for pppoe(8) w/ ppp(8)
On 2012/01/29 14:18, Ben Gould wrote: > Hi All, > > The following is tested with: > > Stock 5.0 as client & server. > These modification to 5.0 client & server. > Recent pppoe(4) patches for RFC 4638 support applied to 5.0 as the client. > > It appears to be broken in with -current from a few days ago + these > mods as the server; although if I run ktrace on the server's spawned > ppp(8) then it appears to work just after the ktrace attaches... It's not totally clear to me from this which combinations work and which don't, could you make that more explicit please? Also your diff is broken in various ways, please send me a tar of the directory off-list and I'll fix it.
Re: man segfault diff
Fix my own 'emtpy' typo, spotted by Theo.
Index: config.h
===
RCS file: /home/vcs/cvs/openbsd/src/usr.bin/man/config.h,v
retrieving revision 1.5
diff -u -p -r1.5 config.h
--- config.h15 Sep 2004 22:20:03 - 1.5
+++ config.h31 Jan 2012 19:38:00 -
@@ -38,13 +38,11 @@ typedef struct _tag {
TAILQ_HEAD(tqh, _entry) list; /* Queue of entries. */
char *s;/* Associated string. */
- size_t len; /* Length of 's'. */
} TAG;
typedef struct _entry {
TAILQ_ENTRY(_entry) q; /* Queue of entries. */
char *s;/* Associated string. */
- size_t len; /* Length of 's'. */
} ENTRY;
TAILQ_HEAD(_head, _tag);
Index: man.c
===
RCS file: /home/vcs/cvs/openbsd/src/usr.bin/man/man.c,v
retrieving revision 1.44
diff -u -p -r1.44 man.c
--- man.c 5 Jan 2012 21:46:15 - 1.44
+++ man.c 31 Jan 2012 19:38:00 -
@@ -95,7 +95,6 @@ main(int argc, char *argv[])
extern char *optarg;
extern int optind;
TAG *searchlist;
- ENTRY *ep;
glob_t pg;
size_t len;
int ch, f_cat, f_how, found;
@@ -339,6 +338,10 @@ parse_path(TAG *t, char *path)
char *p, *slashp;
while ((p = strsep(&path, ":")) != NULL) {
+ /* Skip empty fields */
+ if (*p == '\0')
+ continue;
+
if ((ep = malloc(sizeof(ENTRY))) == NULL)
err(1, NULL);
@@ -434,7 +437,7 @@ manual(char *page, TAG *tag, glob_t *pg)
{
ENTRY *ep, *e_sufp, *e_tag;
TAG *missp, *sufp;
- int anyfound, cnt, found, globres;
+ int anyfound, cnt, found;
char *p, buf[MAXPATHLEN];
anyfound = 0;
Re: ALPS Touchpads and "pms0: not in sync yet"
On 31/01/12(Tue) 16:52, Martin Pieuchot wrote: > Diff below add support for the missing ALPS Dualpoint touchpads to the > pms(4) driver. Most of the work has been done by shadchin@ and should > fix issues you may have seen since pms(4) supports others ALPS devices > (2011/10). > > It adds support for a slightly different version of the ALPS protocol, > which send 'interleaved' PS2 packets in between absolute ALPS packets. > Dell laptops (E6xxx and E5500 at least) have this kind of touchpad. > > You may have notice the problem if you see "pms0: not in sync yet" as > soon as you move your clitpad. This error may also appear if you have a touchpad model 0x633b with a -current system prior to 2012-01-29. If it's your case, upgrading to a newer snapshot will fix this. $ dmesg |grep ALPS pms0: ALPS Dualpoint, version 0x633b Martin
Re: tcpbench: setpgid
* Erik Lax [2012-01-31 16:51]: > I noticed that tcpbench tries to setpgid() for no obvious reason (to > me) since it's not forked anymore. Previously, 2 years ago it was > fork()ed and utilized killpg() etc. Could this be a leftover? I'm > running into issues spawning tcpbench since my parent process uses > setsid(). you're right. good catch! -- Henning Brauer, h...@bsws.de, henn...@openbsd.org BS Web Services, http://bsws.de, Full-Service ISP Secure Hosting, Mail and DNS Services. Dedicated Servers, Root to Fully Managed Henning Brauer Consulting, http://henningbrauer.com/
El Credito y la Cobranza... Una Actividad de Exito en MEX - GDL - MTY
CURSO TALLER El Credito y la Cobranza... Una Actividad de Exito Duracion: (1 dia) 8 hrs. Inversion: $4,150 pesos mas IVA Objetivo: Conocer por medio de practicas vivenciales las razones por las que una empresa tiene ixito al otorgar cridito de forma sana acompaqada de una buena administracisn de la cartera. En la cual la observancia de las medidas preventivas se privilegie a las correctivas, obteniendo grandes utilidades. Dirigido a: Gerentes financieros, contralores, gerentes de cridito, gerentes de cobranza, ejecutivos de cridito, jefes de cobranza y a todos aquellos que tienen trato directo con ventas a cridito. MEXICO, D.F. GUADALAJARA MONTERREY 04 de Febrero Solicite Temario de Click Aqui 08 de Febrero Solicite Temario de Click Aqui 10 de Febrero Solicite Temario de Click Aqui Cursos de Credito y Cobranza - SIMCA CAPACITACION - [IMAGE] Curso Taller Negociacion en la Cobranza para una Efectiva Recuperacion de la Cartera 03 de Febrero - Mexico / 07 de Febrero - Guadalajara / 09 de Febrero - Monterrey [IMAGE] Curso Taller Casos Practicos en el Otorgamiento del Credito y Recuperacion de la Cartera 11 de Febrero - Mexico / 21 de Febrero - Guadalajara / 17 de Febrero - Monterrey [IMAGE] Curso Taller Tecnicas Especializadas en los Procesos de Credito y Cobranza 18 de Febrero - Mexico / 22 de Febrero - Guadalajara / 24 de Febrero - Monterrey [IMAGE] Curso Taller Aprenda a otorgar creditos sanos, prevenga y recupere su cartera vencida 25 de Febrero - Mexico / 27 de Marzo - Guadalajara / 28 de Marzo - Monterrey [IMAGE] Curso Taller Tecnicas Efectivas para Negociar la Cobranza 17 de Febrero - Guadalajara / 10 de Febrero - Mexico / 24 de Febrero - Monterrey Consulte nuestro Catalogo de Cursos Privados - Incompany - In house de Credito y Cobranzas AQUI Diseqamos el curso a la medida de sus necesidades..!Impartimos CURSOS de forma PRIVADA en su empresa, envienos un correo especificando el numero de participantes, el lugar donde se impartira, su nombre, cargo, empresa y telefono.SOLICITE COTIZACION de Click Aqui Consulte la Programacion por Area Credito y Cobranza Recursos Humanos Manufactura y Produccion Adquisiciones y Obras Publicas Seguridad e Higiene Desarrollo Humano Negociacion y Compras Ventas Finanzas Alimentos y Bebidas Asistentes y Secretarias Nuevas Tecnologias Si necesita mayor informacion,comuniquese un Asesor lo atendera de inmediato. SIMCA CAPACITACION Entrenamiento Especializado E-MAIL: simca_capacitac...@hotmail.com Messenger: simca_capacitac...@hotmail.com Lada sin costo: 01 800 543 32 30 Comentanos ?Que curso necesitas? Envianos un correo Da Click Aqui Solicitala a tu Asesor. Si usted no desea que le enviemos mas invitaciones, de Click Aqui, gracias.
Re: tcpbench: setpgid
On 31 January 2012 13:50, Erik Lax wrote:
> Hi,
>
> I noticed that tcpbench tries to setpgid() for no obvious reason (to me)
> since it's not forked anymore. Previously, 2 years ago it was fork()ed and
> utilized killpg() etc. Could this be a leftover? I'm running into issues
> spawning tcpbench since my parent process uses setsid().
>
> I attached a patch (against 5.0) to remove the code :)
>
> Regards
> Erik Lax
>
> Index: usr.bin/tcpbench/tcpbench.c
> ===
> RCS file: /cvs/src/usr.bin/tcpbench/tcpbench.c,v
> retrieving revision 1.22
> diff -u -r1.22 tcpbench.c
> --- usr.bin/tcpbench/tcpbench.c 21 Jun 2011 17:31:07 - 1.22
> +++ usr.bin/tcpbench/tcpbench.c 31 Jan 2012 10:27:50 -
> @@ -703,9 +703,6 @@
>struct event *ev;
>nfds_t lnfds;
>
> - if (setpgid(0, 0) == -1)
> - err(1, "setpgid");
> -
>lnfds = 0;
>for (ai = aitop; ai != NULL; ai = ai->ai_next) {
>saddr_ntop(ai->ai_addr, ai->ai_addrlen, tmp, sizeof(tmp));
>
Commited, thanks
add missing ipad usbdevs entries + quirks.
Allows gphoto2 for PTP transfers, plus other libusb stuff in the future.
-Bryan.
Index: uaudio.c
===
RCS file: /cvs/src/sys/dev/usb/uaudio.c,v
retrieving revision 1.94
diff -u -p -u -r1.94 uaudio.c
--- uaudio.c26 Jan 2012 09:00:36 - 1.94
+++ uaudio.c30 Jan 2012 23:25:23 -
@@ -207,6 +207,10 @@ struct uaudio_devs {
UAUDIO_FLAG_BAD_AUDIO },
{ { USB_VENDOR_APPLE, USB_PRODUCT_APPLE_IPOD_TOUCH_4G },
UAUDIO_FLAG_BAD_AUDIO },
+ { { USB_VENDOR_APPLE, USB_PRODUCT_APPLE_IPAD },
+ UAUDIO_FLAG_BAD_AUDIO },
+ { { USB_VENDOR_APPLE, USB_PRODUCT_APPLE_IPAD2 },
+ UAUDIO_FLAG_BAD_AUDIO },
{ { USB_VENDOR_CREATIVE, USB_PRODUCT_CREATIVE_EMU0202 },
UAUDIO_FLAG_VENDOR_CLASS | UAUDIO_FLAG_EMU0202 |
UAUDIO_FLAG_DEPENDENT },
Index: usb_quirks.c
===
RCS file: /cvs/src/sys/dev/usb/usb_quirks.c,v
retrieving revision 1.65
diff -u -p -u -r1.65 usb_quirks.c
--- usb_quirks.c1 Dec 2011 23:02:12 - 1.65
+++ usb_quirks.c30 Jan 2012 23:25:23 -
@@ -120,7 +120,9 @@ const struct usbd_quirk_entry {
{ USB_VENDOR_APPLE, USB_PRODUCT_APPLE_IPOD_TOUCH, ANY,{ UQ_BAD_HID }},
{ USB_VENDOR_APPLE, USB_PRODUCT_APPLE_IPOD_TOUCH_2G, ANY,{ UQ_BAD_HID }},
{ USB_VENDOR_APPLE, USB_PRODUCT_APPLE_IPOD_TOUCH_3G, ANY,{ UQ_BAD_HID }},
- { USB_VENDOR_APPLE, USB_PRODUCT_APPLE_IPOD_TOUCH_4G, ANY,{ UQ_BAD_HID
}},
+ { USB_VENDOR_APPLE, USB_PRODUCT_APPLE_IPOD_TOUCH_4G, ANY,{ UQ_BAD_HID }},
+ { USB_VENDOR_APPLE, USB_PRODUCT_APPLE_IPAD, ANY,{ UQ_BAD_HID }},
+ { USB_VENDOR_APPLE, USB_PRODUCT_APPLE_IPAD2, ANY,{ UQ_BAD_HID }},
{ USB_VENDOR_APPLE, USB_PRODUCT_APPLE_SPEAKERS, ANY,{ UQ_BAD_HID }},
{ USB_VENDOR_BELKIN, USB_PRODUCT_BELKIN_F6C100, ANY,{ UQ_BAD_HID }},
{ USB_VENDOR_BELKIN, USB_PRODUCT_BELKIN_F6C120, ANY,{ UQ_BAD_HID }},
Index: usbdevs
===
RCS file: /cvs/src/sys/dev/usb/usbdevs,v
retrieving revision 1.570
diff -u -p -u -r1.570 usbdevs
--- usbdevs 29 Jan 2012 10:59:23 - 1.570
+++ usbdevs 30 Jan 2012 23:25:24 -
@@ -893,8 +893,10 @@ product APPLE IPOD_TOUCH_2G0x1293 iPod
product APPLE IPHONE_3GS 0x1294 iPhone 3GS
product APPLE IPHONE_4_GSM 0x1297 iPhone 4 GSM
product APPLE IPOD_TOUCH_3G0x1299 iPod Touch 3G
+product APPLE IPAD 0x129a iPad
product APPLE IPHONE_4_CDMA0x129c iPhone 4 CDMA
product APPLE IPOD_TOUCH_4G0x129e iPod Touch 4G
+product APPLE IPAD20x129f iPad 2
product APPLE IPHONE_4S0x12a0 iPhone 4S
product APPLE ETHERNET 0x1402 Ethernet A1277
product APPLE BLUETOOTH2 0x8205 Bluetooth
Re: tcpbench: setpgid
On 31 January 2012 13:50, Erik Lax wrote:
> Hi,
>
> I noticed that tcpbench tries to setpgid() for no obvious reason (to me)
> since it's not forked anymore. Previously, 2 years ago it was fork()ed and
> utilized killpg() etc. Could this be a leftover? I'm running into issues
> spawning tcpbench since my parent process uses setsid().
>
> I attached a patch (against 5.0) to remove the code :)
>
You're correct nice catch :-).
> Regards
> Erik Lax
>
> Index: usr.bin/tcpbench/tcpbench.c
> ===
> RCS file: /cvs/src/usr.bin/tcpbench/tcpbench.c,v
> retrieving revision 1.22
> diff -u -r1.22 tcpbench.c
> --- usr.bin/tcpbench/tcpbench.c 21 Jun 2011 17:31:07 - 1.22
> +++ usr.bin/tcpbench/tcpbench.c 31 Jan 2012 10:27:50 -
> @@ -703,9 +703,6 @@
>struct event *ev;
>nfds_t lnfds;
>
> - if (setpgid(0, 0) == -1)
> - err(1, "setpgid");
> -
>lnfds = 0;
>for (ai = aitop; ai != NULL; ai = ai->ai_next) {
>saddr_ntop(ai->ai_addr, ai->ai_addrlen, tmp, sizeof(tmp));
ALPS Touchpads and "pms0: not in sync yet"
Diff below add support for the missing ALPS Dualpoint touchpads to the
pms(4) driver. Most of the work has been done by shadchin@ and should
fix issues you may have seen since pms(4) supports others ALPS devices
(2011/10).
It adds support for a slightly different version of the ALPS protocol,
which send 'interleaved' PS2 packets in between absolute ALPS packets.
Dell laptops (E6xxx and E5500 at least) have this kind of touchpad.
You may have notice the problem if you see "pms0: not in sync yet" as
soon as you move your clitpad.
Please report any breakage to shadchin@ and myself.
Martin
Index: pms.c
===
RCS file: /cvs/src/sys/dev/pckbc/pms.c,v
retrieving revision 1.27
diff -u -p -r1.27 pms.c
--- pms.c 28 Jan 2012 21:00:48 - 1.27
+++ pms.c 30 Jan 2012 10:41:36 -
@@ -87,6 +87,11 @@ struct synaptics_softc {
struct alps_softc {
int model;
+#define ALPS_GLIDEPOINT(1 << 1)
+#define ALPS_DUALPOINT (1 << 2)
+#define ALPS_PASSTHROUGH (1 << 3)
+#define ALPS_INTERLEAVED (1 << 4)
+
int mask;
int version;
@@ -94,6 +99,8 @@ struct alps_softc {
int max_x, max_y;
int old_fin;
+ u_int sec_buttons; /* trackpoint */
+
/* Compat mode */
int wsmode;
int old_x, old_y;
@@ -145,18 +152,15 @@ static const struct alps_model {
int mask;
int model;
} alps_models[] = {
-#if 0
- /* FIXME some clipads are not working yet */
- { 0x5212, 0xff, ALPS_DUALPOINT | ALPS_PASSTHROUGH },
- { 0x6222, 0xcf, ALPS_DUALPOINT | ALPS_PASSTHROUGH },
-#endif
{ 0x2021, 0xf8, ALPS_DUALPOINT | ALPS_PASSTHROUGH },
{ 0x2221, 0xf8, ALPS_DUALPOINT | ALPS_PASSTHROUGH },
{ 0x, 0xff, ALPS_DUALPOINT | ALPS_PASSTHROUGH },
{ 0x3222, 0xf8, ALPS_DUALPOINT | ALPS_PASSTHROUGH },
+ { 0x5212, 0xff, ALPS_DUALPOINT | ALPS_PASSTHROUGH | ALPS_INTERLEAVED },
{ 0x5321, 0xf8, ALPS_GLIDEPOINT },
{ 0x5322, 0xf8, ALPS_GLIDEPOINT },
{ 0x603b, 0xf8, ALPS_GLIDEPOINT },
+ { 0x6222, 0xcf, ALPS_DUALPOINT | ALPS_PASSTHROUGH | ALPS_INTERLEAVED },
{ 0x6321, 0xf8, ALPS_GLIDEPOINT },
{ 0x6322, 0xf8, ALPS_GLIDEPOINT },
{ 0x6323, 0xf8, ALPS_GLIDEPOINT },
@@ -228,6 +232,7 @@ int synaptics_query(struct pms_softc *,
intsynaptics_get_hwinfo(struct pms_softc *);
void synaptics_sec_proc(struct pms_softc *);
+intalps_sec_proc(struct pms_softc *);
intalps_get_hwinfo(struct pms_softc *);
struct cfattach pms_ca = {
@@ -726,6 +731,7 @@ pmsinput(void *vsc, int data)
return;
}
+ sc->packet[sc->inputstate] = data;
if (sc->protocol->sync(sc, data)) {
#ifdef DIAGNOSTIC
printf("%s: not in sync yet, discard input\n", DEVNAME(sc));
@@ -734,13 +740,13 @@ pmsinput(void *vsc, int data)
return;
}
- sc->packet[sc->inputstate++] = data;
+ sc->inputstate++;
if (sc->inputstate != sc->protocol->packetsize)
return;
- sc->protocol->proc(sc);
sc->inputstate = 0;
+ sc->protocol->proc(sc);
}
int
@@ -1050,6 +1056,40 @@ pms_disable_synaptics(struct pms_softc *
}
int
+alps_sec_proc(struct pms_softc *sc)
+{
+ struct alps_softc *alps = sc->alps;
+ int dx, dy, pos = 0;
+
+ if ((sc->packet[0] & PMS_ALPS_PS2_MASK) == PMS_ALPS_PS2_VALID) {
+ /*
+* We need to keep buttons states because interleaved
+* packets only signalize x/y movements.
+*/
+ alps->sec_buttons = butmap[sc->packet[0] & PMS_PS2_BUTTONSMASK];
+ } else if ((sc->packet[3] & PMS_ALPS_INTERLEAVED_MASK) ==
+ PMS_ALPS_INTERLEAVED_VALID) {
+ sc->inputstate = 3;
+ pos = 3;
+ } else {
+ return (0);
+ }
+
+ if ((sc->sc_dev_enable & PMS_DEV_SECONDARY) == 0)
+ return (1);
+
+ dx = (sc->packet[pos] & PMS_PS2_XNEG) ?
+ (int)sc->packet[pos + 1] - 256 : sc->packet[pos + 1];
+ dy = (sc->packet[pos] & PMS_PS2_YNEG) ?
+ (int)sc->packet[pos + 2] - 256 : sc->packet[pos + 2];
+
+ wsmouse_input(sc->sc_sec_wsmousedev, alps->sec_buttons,
+ dx, dy, 0, 0, WSMOUSE_INPUT_DELTA);
+
+ return (1);
+}
+
+int
alps_get_hwinfo(struct pms_softc *sc)
{
struct alps_softc *alps = sc->alps;
@@ -1161,6 +1201,8 @@ pms_enable_alps(struct pms_softc *sc)
goto err;
}
+ alps->sec_buttons = 0;
+
return (1);
err:
@@ -1205,6 +1247,13 @@ pms_sync_alps(struct pms_softc *sc, int
{
struct alps_softc *alps = sc->alps;
+ if ((alps->model & ALPS_DUALPOINT) &&
+ (sc->packet[0] & PMS_ALPS_PS2_MASK) == PMS_ALPS_PS2_VALID) {
+ if (sc->inputstate == 2)
+ sc->inputstate += 3;
+
tcpbench: setpgid
Hi,
I noticed that tcpbench tries to setpgid() for no obvious reason (to me)
since it's not forked anymore. Previously, 2 years ago it was fork()ed
and utilized killpg() etc. Could this be a leftover? I'm running into
issues spawning tcpbench since my parent process uses setsid().
I attached a patch (against 5.0) to remove the code :)
Regards
Erik Lax
Index: usr.bin/tcpbench/tcpbench.c
===
RCS file: /cvs/src/usr.bin/tcpbench/tcpbench.c,v
retrieving revision 1.22
diff -u -r1.22 tcpbench.c
--- usr.bin/tcpbench/tcpbench.c 21 Jun 2011 17:31:07 - 1.22
+++ usr.bin/tcpbench/tcpbench.c 31 Jan 2012 10:27:50 -
@@ -703,9 +703,6 @@
struct event *ev;
nfds_t lnfds;
- if (setpgid(0, 0) == -1)
- err(1, "setpgid");
-
lnfds = 0;
for (ai = aitop; ai != NULL; ai = ai->ai_next) {
saddr_ntop(ai->ai_addr, ai->ai_addrlen, tmp, sizeof(tmp));
Re: Keycode print mode (-r) for wsconsctl(8)
Tobias Stoeckmann suggested off-list to keep explicit state of
wether rawmode is enabled or not, so that the signal handler
doesn't perform useless (and wrong, strictly speaking) work.
He also suggested to integrate keycode.c into wsconsctl.c (if
i understood correctly ;), but i was unsure about that.
And the usage string for -r erroneously and unfortunately
contained '-f [xy]', which this diff also fixes.
I'll watch out and see if i find my heart drops somewhere.
Thanks again.
--steffen
Index: Makefile
===
RCS file: /Users/steffen/arena/code.openbsd/src/sbin/wsconsctl/Makefile,v
retrieving revision 1.34
diff -a -p -u -r1.34 Makefile
--- Makefile30 Jan 2010 20:48:50 - 1.34
+++ Makefile30 Jan 2012 15:17:46 -
@@ -12,7 +12,7 @@
${MACHINE} == "zaurus"
PROG= wsconsctl
-SRCS= display.c keyboard.c keysym.c map_parse.y map_scan.l \
+SRCS= display.c keyboard.c keycode.c keysym.c map_parse.y map_scan.l \
mouse.c util.c wsconsctl.c
CPPFLAGS+= -I${.CURDIR} -I.
Index: keycode.c
===
RCS file: keycode.c
diff -N keycode.c
--- /dev/null 1 Jan 1970 00:00:00 -
+++ keycode.c 31 Jan 2012 13:46:22 -
@@ -0,0 +1,139 @@
+/* $OpenBSD$ */
+
+/*
+ * Copyright (c) 2012 Steffen Daode Nurpmeso.
+ * All rights reserved.
+ *
+ * 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.
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include "wsconsctl.h"
+
+static int is_rawmode;
+static struct termios tios_orig, tios_raw;
+
+static voidonsig(int sig);
+static voidraw_on(void), raw_off(void);
+
+static void
+onsig(int sig)
+{
+ if (is_rawmode)
+ raw_off();
+ exit(sig != SIGALRM);
+}
+
+static void
+raw_on(void)
+{
+ int arg = WSKBD_RAW;
+
+ if (tcsetattr(STDIN_FILENO, TCSANOW, &tios_raw) < 0)
+ err(1, "Can't set terminal attributes");
+ if (ioctl(STDIN_FILENO, WSKBDIO_SETMODE, &arg) < 0) {
+ arg = errno;
+ (void)tcsetattr(STDIN_FILENO, TCSANOW, &tios_orig);
+ errno = arg;
+ err(1, ((arg == ENOTTY)
+ ? "This mode won't work on pseudo terminals"
+ : "Can't put keyboard in raw mode (the "
+ "WSDISPLAY_COMPAT_RAWKBD kernel option is required)"));
+ }
+
+ is_rawmode = 1;
+ return;
+}
+
+static void
+raw_off(void)
+{
+ int arg = WSKBD_TRANSLATED;
+
+ (void)ioctl(STDIN_FILENO, WSKBDIO_SETMODE, &arg);
+ (void)tcsetattr(STDIN_FILENO, TCSANOW, &tios_orig);
+
+ is_rawmode = 0;
+ return;
+}
+
+void
+keycode_mode(void)
+{
+ ssize_t i, skip;
+ struct sigaction sa;
+ struct itimerval it;
+ unsigned char *cursor, buffer[64];
+
+ if (tcgetattr(STDIN_FILENO, &tios_orig) < 0)
+ err(1, "Can't query terminal attributes");
+ tios_raw = tios_orig;
+ (void)cfmakeraw(&tios_raw);
+
+ sa.sa_handler = &onsig;
+ sa.sa_flags = 0;
+ (void)sigfillset(&sa.sa_mask);
+ for (i = 0; i < NSIG; ++i)
+ if (sigaction((int)i + 1, &sa, NULL) < 0 && i == SIGALRM)
+ err(1, "Can't install SIGALRM signal handler");
+
+ printf("You may now use the keyboard.\n"
+ "After five seconds of inactivity the program terminates\n");
+ for (i = skip = 0;;) {
+ it.it_value.tv_sec = 5;
+ it.it_value.tv_usec = 0;
+ it.it_interval.tv_sec = it.it_interval.tv_usec = 0;
+ if (setitimer(ITIMER_REAL, &it, NULL) < 0)
+ err(3, "Can't install wakeup timer");
+
+ raw_on();
+ i = read(STDIN_FILENO, buffer + skip, sizeof(buffer) - skip);
+ raw_off();
+
+ it.it_value.tv_sec = it.it_value.tv_usec = 0;
+ (void)setitimer(ITIMER_REAL, &it, NULL);
+
+ if (i <= 0)
+ exit(1);
+ i += skip;
+
+ for (cursor = buffer; --i >= 0;) {
+ unsigned int k = *cursor++;
+
Re: diff: fix LCP keepalive failures on L2TP.
Hi, On Tue, 31 Jan 2012 13:59:17 +0100 "Sebastian Reitenbach" wrote: > However, I noted with tcpdump, listening on tun0: > # tcpdump -n -i tun0 > tcpdump: listening on tun0, link-type LOOP > 13:51:15.354776 > tcpdump: WARNING: compensating for unaligned libpcap packets > 13:51:15.354795 10.66.66.1 > 10.66.66.129: icmp: echo reply (DF) > 13:51:16.334984 > 13:51:16.334997 10.66.66.1 > 10.66.66.129: icmp: echo reply (DF) > 13:51:17.355463 (snip) > # tcpdump -n -i tun0 -s 2000 -X > tcpdump: listening on tun0, link-type LOOP > 13:55:32.395223 > : 4500 0054 4000 4001 a1a3 0a42 4281 E..T..@.@BB. > 0010: 0a42 4201 0800 6b54 6063 08bc 43e5 274f .BB...kT`c..C.'O > 0020: c554 0800 0809 0a0b 0c0d 0e0f 1011 1213 .T.. > 0030: 1415 1617 1819 1a1b 1c1d 1e1f 2021 2223 !"# > 0040: 2425 2627 2829 2a2b 2c2d 2e2f 3031 3233 $%&'()*+,-./0123 > 0050: 3435 36374567 This is a separate issue. I'll look into this. Thank you for your tests and reports. --yasuoka
Re: diff: fix LCP keepalive failures on L2TP.
On Tuesday, January 31, 2012 10:02 CET, "Sebastian Reitenbach" wrote: > On Monday, January 30, 2012 15:43 CET, YASUOKA Masahiko > wrote: > > > On Mon, 30 Jan 2012 22:49:22 +0900 (JST) > > YASUOKA Masahiko wrote: > > > pipex hook in udp_usrreq() mistakenly assumed that `inp' is > > > connected. The hook could not use the destination address properly, > > > so it failed to find the pipex session. This bug caused LCP keepalive > > > failures on L2TP from client that does LCP keepalive and uses sequence > > > number on the L2TP data channel (xl2tpd + pppd). > > > > > > The diff includes kernel header file changes. > > > > > > ok? > > > > Oops. Let me update the diff. > > > > The given struct sockaddr object of > > pipex_l2tp_userland_lookup_session() became passed from the userland, > > so its address family must be checked. > > > > ok? > > tested IPSec/L2TP with xl2tpd, strongswan client. I did setup the tunnel > yesterday > evening, and its still alive this morning. Without the patch, the tunnel > usually died after > a couple of minutes. > > So this definitely works for me, but I'm probably not the right guy to OK > that in this phase of > release cycle. > > I'll now try with Android phone, since I've seen the same problems with dying > tunnel too. The tunnel established with Android 2.2, now also seems to be stable, at least for the last two hours and 15 minutes. Prior to the patch, like with the Linux client, the tunnel died within a couple of minutes, maybe half an hour or hour. However, I noted with tcpdump, listening on tun0: # tcpdump -n -i tun0 tcpdump: listening on tun0, link-type LOOP 13:51:15.354776 tcpdump: WARNING: compensating for unaligned libpcap packets 13:51:15.354795 10.66.66.1 > 10.66.66.129: icmp: echo reply (DF) 13:51:16.334984 13:51:16.334997 10.66.66.1 > 10.66.66.129: icmp: echo reply (DF) 13:51:17.355463 13:51:17.355474 10.66.66.1 > 10.66.66.129: icmp: echo reply (DF) 13:51:18.375712 13:51:18.375722 10.66.66.1 > 10.66.66.129: icmp: echo reply (DF) 13:51:19.354994 13:51:19.355004 10.66.66.1 > 10.66.66.129: icmp: echo reply (DF) 13:51:20.375274 13:51:20.375285 10.66.66.1 > 10.66.66.129: icmp: echo reply (DF) 13:51:21.355354 13:51:21.355364 10.66.66.1 > 10.66.66.129: icmp: echo reply (DF) 13:51:22.334948 13:51:22.334959 10.66.66.1 > 10.66.66.129: icmp: echo reply (DF) 13:51:23.394820 13:51:23.394831 10.66.66.1 > 10.66.66.129: icmp: echo reply (DF) 13:51:24.374594 13:51:24.374605 10.66.66.1 > 10.66.66.129: icmp: echo reply (DF) 13:51:25.394998 13:51:25.395009 10.66.66.1 > 10.66.66.129: icmp: echo reply (DF) 13:51:26.394767 13:51:26.394777 10.66.66.1 > 10.66.66.129: icmp: echo reply (DF) 13:51:27.415028 13:51:27.415039 10.66.66.1 > 10.66.66.129: icmp: echo reply (DF) 13:51:28.375882 13:51:28.375892 10.66.66.1 > 10.66.66.129: icmp: echo reply (DF) Also when I show the contents with -X: # tcpdump -n -i tun0 -s 2000 -X tcpdump: listening on tun0, link-type LOOP 13:55:32.395223 : 4500 0054 4000 4001 a1a3 0a42 4281 E..T..@.@BB. 0010: 0a42 4201 0800 6b54 6063 08bc 43e5 274f .BB...kT`c..C.'O 0020: c554 0800 0809 0a0b 0c0d 0e0f 1011 1213 .T.. 0030: 1415 1617 1819 1a1b 1c1d 1e1f 2021 2223 !"# 0040: 2425 2627 2829 2a2b 2c2d 2e2f 3031 3233 $%&'()*+,-./0123 0050: 3435 36374567 tcpdump: WARNING: compensating for unaligned libpcap packets 13:55:32.395249 10.66.66.1 > 10.66.66.129: icmp: echo reply (DF) : 8266 4000 ff01 603c 0a42 4201 0a42 4281 .f@...`<.BB..BB. 0010: 7354 6063 08bc 43e5 274f c554 0800 ..sT`c..C.'O.T.. 0020: 0809 0a0b 0c0d 0e0f 1011 1213 1415 1617 0030: 1819 1a1b 1c1d 1e1f 2021 2223 2425 2627 !"#$%&' 0040: 2829 2a2b 2c2d 2e2f 3031 3233 3435 3637 ()*+,-./01234567 0050: 13:55:34.315241 : 4500 0054 4000 4001 a1a3 0a42 4281 E..T..@.@BB. 0010: 0a42 4201 0800 5e54 6063 08bd 44e5 274f .BB...^T`c..D.'O 0020: d153 0800 0809 0a0b 0c0d 0e0f 1011 1213 .S.. 0030: 1415 1617 1819 1a1b 1c1d 1e1f 2021 2223 !"# 0040: 2425 2627 2829 2a2b 2c2d 2e2f 3031 3233 $%&'()*+,-./0123 0050: 3435 36374567 13:55:34.315253 10.66.66.1 > 10.66.66.129: icmp: echo reply (DF) : cd82 4000 ff01 1520 0a42 4201 0a42 4281 ..@ .BB..BB. 0010: 6654 6063 08bd 44e5 274f d153 0800 ..fT`c..D.'O.S.. 0020: 0809 0a0b 0c0d 0e0f 1011 1213 1415 1617 0030: 1819 1a1b 1c1d 1e1f 2021 2223 2425 2627 !"#$%&' 0040: 2829 2a2b 2c2d 2e2f 3031 3233 3435 3637 ()*+,-./01234567 0050: 13:55:34.994293 : 4500 0054 4000 4001 a1a3 0a42 4281 E..T..@.@BB. 0010: 0a42 4201 0800 8752 6063 08be 45e5 274f .BBR`c..E.'O 0020: a754 0800 0809 0a0b 0c0d 0e0f 1011 1213 .T.. 0030: 1415 1617 1819 1a1b 1c1d 1e1f 2
Re: diff: fix LCP keepalive failures on L2TP.
On Monday, January 30, 2012 15:43 CET, YASUOKA Masahiko
wrote:
> On Mon, 30 Jan 2012 22:49:22 +0900 (JST)
> YASUOKA Masahiko wrote:
> > pipex hook in udp_usrreq() mistakenly assumed that `inp' is
> > connected. The hook could not use the destination address properly,
> > so it failed to find the pipex session. This bug caused LCP keepalive
> > failures on L2TP from client that does LCP keepalive and uses sequence
> > number on the L2TP data channel (xl2tpd + pppd).
> >
> > The diff includes kernel header file changes.
> >
> > ok?
>
> Oops. Let me update the diff.
>
> The given struct sockaddr object of
> pipex_l2tp_userland_lookup_session() became passed from the userland,
> so its address family must be checked.
>
> ok?
tested IPSec/L2TP with xl2tpd, strongswan client. I did setup the tunnel
yesterday
evening, and its still alive this morning. Without the patch, the tunnel
usually died after
a couple of minutes.
So this definitely works for me, but I'm probably not the right guy to OK that
in this phase of
release cycle.
I'll now try with Android phone, since I've seen the same problems with dying
tunnel too.
Sebastian
>
> Index: sys/net/pipex.c
> ===
> RCS file: /cvs/src/sys/net/pipex.c,v
> retrieving revision 1.25
> diff -u -p -r1.25 pipex.c
> --- sys/net/pipex.c 23 Jan 2012 03:36:21 - 1.25
> +++ sys/net/pipex.c 30 Jan 2012 14:37:31 -
> @@ -2210,13 +2210,16 @@ pipex_l2tp_userland_lookup_session_ipv6(
> }
> #endif
>
> -Static struct pipex_session *
> +struct pipex_session *
> pipex_l2tp_userland_lookup_session(struct mbuf *m0, struct sockaddr *sa)
> {
> struct pipex_l2tp_header l2tp;
> struct pipex_hash_head *list;
> struct pipex_session *session;
> uint16_t session_id, tunnel_id, flags;
> +
> + if (sa->sa_family != AF_INET && sa->sa_family != AF_INET6)
> + return (NULL);
>
> /* pullup */
> if (m0->m_pkthdr.len < sizeof(l2tp)) {
> Index: sys/net/pipex.h
> ===
> RCS file: /cvs/src/sys/net/pipex.h,v
> retrieving revision 1.11
> diff -u -p -r1.11 pipex.h
> --- sys/net/pipex.h 23 Jan 2012 03:36:21 - 1.11
> +++ sys/net/pipex.h 30 Jan 2012 14:37:31 -
> @@ -210,6 +210,7 @@ struct pipex_session *pipex_pptp_lookup
> struct mbuf *pipex_pptp_input (struct mbuf *, struct pipex_session
> *);
> struct pipex_session *pipex_pptp_userland_lookup_session_ipv4 (struct mbuf
> *, struct in_addr);
> struct pipex_session *pipex_pptp_userland_lookup_session_ipv6 (struct mbuf
> *, struct in6_addr);
> +struct pipex_session *pipex_l2tp_userland_lookup_session(struct mbuf *,
> struct sockaddr *);
> struct mbuf *pipex_pptp_userland_output (struct mbuf *, struct
> pipex_session *);
> struct pipex_session *pipex_l2tp_lookup_session (struct mbuf *, int);
> struct mbuf *pipex_l2tp_input (struct mbuf *, int off, struct
> pipex_session *);
> Index: sys/net/pipex_local.h
> ===
> RCS file: /cvs/src/sys/net/pipex_local.h,v
> retrieving revision 1.14
> diff -u -p -r1.14 pipex_local.h
> --- sys/net/pipex_local.h 25 Nov 2011 13:05:06 - 1.14
> +++ sys/net/pipex_local.h 30 Jan 2012 14:37:31 -
> @@ -406,7 +406,6 @@ Static struct pipex_session *pipex_pptp
>
> #ifdef PIPEX_L2TP
> Static void pipex_l2tp_output (struct mbuf *, struct
> pipex_session *);
> -Static struct pipex_session *pipex_l2tp_userland_lookup_session(struct mbuf
> *, struct sockaddr *);
> #endif
>
> #ifdef PIPEX_MPPE
> Index: sys/netinet/udp_usrreq.c
> ===
> RCS file: /cvs/src/sys/netinet/udp_usrreq.c,v
> retrieving revision 1.145
> diff -u -p -r1.145 udp_usrreq.c
> --- sys/netinet/udp_usrreq.c 8 Jul 2011 18:30:17 - 1.145
> +++ sys/netinet/udp_usrreq.c 30 Jan 2012 14:37:32 -
> @@ -1198,6 +1198,12 @@ udp_usrreq(struct socket *so, int req, s
> #ifdef PIPEX
> if (inp->inp_pipex) {
> struct pipex_session *session;
> +
> + if (addr != NULL)
> + session =
> + pipex_l2tp_userland_lookup_session(m,
> + mtod(addr, struct sockaddr *));
> + else
> #ifdef INET6
> if (inp->inp_flags & INP_IPV6)
> session =
