Fatal trap 12 in binding V6 socket in FreeBSD 5.1-p2
Has anyone else seen that in the FreeBSD 5.1-p2 if one is binding to a socket
that has earliear been closed but the tcp connection is still in time wait
state will cause a panic in kernel with following error code:
Fatal trap 12: page fault while in kernel mode
fault virtual address = 0x6
fault code = supervisor read, page not present
instruction pointer = 0x8:0xc03aa50e
stack pointer = 0x10:0xdcc62c0c
frame pointer = 0x10:0xdcc62c54
code segment= base 0x0, limit 0xf, type 0x1b
= DPL 0, pres 1, def32 1, gran 1
processor eflags= interrupt enabled, resume, IOPL = 0
current process = 33485
trap number = 12
panic: page fault
It seems that the problem is in the in6_pcbbind where the in6_pcblookup_local
is called (in6_pcb.c:231). If the socket has been closed the t->inp_socket
struct has been already freed and set null but the t exists because there
exists a state time wait still for the connection and that's why the
lookup_local will return a valid value for t. After the lookup_local has
returned the in6_pcbbinf will try to access t->inp_socket->so_options which
of course will cause a Fatal trap because it is a NULL pointer.
I've included as an attachment a patch that I have used to fix the problem and
allso as attached a short program which can be used to regenerate the problem
in unpatched FreeBSD 5.1-p2.
It seems that this problem also exists in the KAME SNAP.
BR. Jan
*** in6_pcb.c Fri Sep 5 09:22:32 2003
--- in6_pcb.c Fri Sep 5 09:44:16 2003
***
*** 888,896
--- 888,906
*/
head = &pcbinfo->hashbase[INP_PCBHASH(INADDR_ANY, lport, 0,
pcbinfo->hashmask)];
+
LIST_FOREACH(inp, head, inp_hash) {
if ((inp->inp_vflag & INP_IPV6) == 0)
continue;
+
+ /*
+ * If the inp_socket is NULL the socket is
+ * already closed and tcp connection is in
+ * time_wait state so just ignore it
+ */
+ if (NULL == inp->inp_socket)
+ continue;
+
if (IN6_IS_ADDR_UNSPECIFIED(&inp->in6p_faddr) &&
IN6_ARE_ADDR_EQUAL(&inp->in6p_laddr, laddr) &&
inp->inp_lport == lport) {
***
*** 929,934
--- 939,953
wildcard = 0;
if ((inp->inp_vflag & INP_IPV6) == 0)
continue;
+
+ /*
+ * If the inp_socket is NULL the socket is
+ * already closed and tcp connection is in
+ * time_wait state so just ignore it
+ */
+ if (NULL == inp->inp_socket)
+ continue;
+
if (!IN6_IS_ADDR_UNSPECIFIED(&inp->in6p_faddr))
wildcard++;
if (!IN6_IS_ADDR_UNSPECIFIED(
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Fatal trap 12 in binding V6 socket in FreeBSD 5.1-p2
> I've included as an attachment a patch that I have used to fix the problem > and allso as attached a short program which can be used to regenerate the > problem in unpatched FreeBSD 5.1-p2. Oops Forgot the other attachment... BR. Jan ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Fatal trap 12 in binding V6 socket in FreeBSD 5.1-p2
On Friday 05 September 2003 12:54, Simon L. Nielsen wrote:
> On 2003.09.05 12:51:14 +0300, Jan Mikael Melen wrote:
> > > I've included as an attachment a patch that I have used to fix the
> > > problem and allso as attached a short program which can be used to
> > > regenerate the problem in unpatched FreeBSD 5.1-p2.
> >
> > Oops Forgot the other attachment...
>
> The attachement at least didn't make it to the FreeBSD-net list. This
> might be useful:
>
> http://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/eresources.html#E
>RESOURCES-MAILFILTERING
Well let's put it in plain text because c-source files seems to be filtered
away on freebsd-net list...
#include
#include
#include
#include
#include
#include
#include
#include
#include
static void
usage(char *progname) {
fprintf(stderr, "Usage: %s ip port\n", progname);
exit (1);
}
int main(int argc, char *argv[]) {
int s1, s2, s3, len, ret, fromlen, i;
char buf[1024];
struct sockaddr_storage ss0;
struct sockaddr_in6 *sin60 = (struct sockaddr_in6 *)&ss0;
struct sockaddr_storage ss;
char *progname = argv[0];
char *scope;
if (argc != 3)
usage(progname);
memset(&ss0, 0, sizeof(ss0));
sin60->sin6_len = sizeof(struct sockaddr_in6);
sin60->sin6_family = AF_INET6;
sin60->sin6_port = htons(atoi(argv[2]));
scope = strchr(argv[1], '%');
if (scope) {
*scope++ = 0;
sin60->sin6_scope_id = atoi(scope);
}
ret = inet_pton(AF_INET6, argv[1], &sin60->sin6_addr.s6_addr);
if (ret <= 0) {
err(1, "%s: %s", progname, "inet_pton");
}
if(fork()) {
for(i=0; i<2; i++) {
sleep(1);
s1 = socket(AF_INET6, SOCK_STREAM, IPPROTO_TCP);
if (s1 < 0) {
err(1, "%s: %s", progname, "socket");
}
ret = connect(s1, (struct sockaddr *)&ss0, ss0.ss_len);
if (ret < 0) {
err(1, "%s: %s", progname, "connect");
}
len = sizeof(ss);
ret = getsockname(s1, (struct sockaddr *)&ss, &len);
if (ret < 0) {
err(1, "%s: %s", progname, "getsockname");
}
ret = send(s1, &ss, ss.ss_len, 0);
if (ret < 0) {
err(1, "%s: %s", progname, "send");
}
close(s1);
}
} else {
for(i=0; i<2; i++) {
s2 = socket(AF_INET6, SOCK_STREAM, IPPROTO_TCP);
if (s2 < 0) {
err(1, "%s: %s", progname, "socket");
}
ret = bind(s2, (struct sockaddr *)&ss0, ss0.ss_len);
if (ret < 0) {
err(1, "%s: %s", progname, "bind");
}
listen(s2, 5);
fromlen = sizeof(ss);
if((s3 = accept(s2, (struct sockaddr *)&ss, &fromlen)) > 0) {
ret = recv(s3, buf, 1024, 0);
if (ret < 0) {
err(1, "%s: %s", progname, "recv");
}
if (memcmp(&buf, &ss, ss.ss_len) != 0) {
printf("accept->receive: [Failed]\n");
}
}
len = sizeof(ss);
ret = getpeername(s3, (struct sockaddr *)&ss, &len);
if (ret < 0) {
err(1, "%s: %s", progname, "getpeername");
}
if (memcmp(&buf, &ss, ss.ss_len) != 0) {
printf("accept->getpeername: [Failed]\n");
}
close(s3);
close(s2);
sleep(1);
}
}
return 1;
}
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Fatal trap 12 in binding V6 socket in FreeBSD 5.1-p2
On Friday 05 September 2003 11:51, Jan Mikael Melen wrote: > > I've included as an attachment a patch that I have used to fix the > > problem and allso as attached a short program which can be used to > > regenerate the problem in unpatched FreeBSD 5.1-p2. > > Oops Forgot the other attachment... > >BR. Jan You've forgotten it twice lol :) -- JFRH ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
adding a teredo node into netgraph
Hi, I'm actually working on a teredo server/relay implementation as a netgraph node. Can you tell me, please, who I need to contact for an eventual integration of my code into the netgraph source. Thanks. Konstantin _ Konstantin K. KABASSANOV Research and Development Engineer LIP6 Laboratory Pierre and Marie Curie University 8, rue du Capitaine Scott, 75015 Paris, France Phone: +33 (0) 1 44 27 71 26 Fax: +33 (0) 1 44 27 74 95 E-mail: [EMAIL PROTECTED] Web: http://www.kabassanov.com __ ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: adding a teredo node into netgraph
On Fri, 5 Sep 2003, Konstantin KABASSANOV wrote: > Hi, > > I'm actually working on a teredo server/relay implementation as a > netgraph node. Can you tell me, please, who I need to contact for an > eventual integration of my code into the netgraph source. contact me.. what is teredo? > > Thanks. > > Konstantin > > _ > > Konstantin K. KABASSANOV > Research and Development Engineer > > LIP6 Laboratory > Pierre and Marie Curie University > > 8, rue du Capitaine Scott, > 75015 Paris, France > > Phone: +33 (0) 1 44 27 71 26 > Fax: +33 (0) 1 44 27 74 95 > > E-mail: [EMAIL PROTECTED] > Web: http://www.kabassanov.com > __ > > > > > ___ > [EMAIL PROTECTED] mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-net > To unsubscribe, send any mail to "[EMAIL PROTECTED]" > ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: adding a teredo node into netgraph
Julian Elischer wrote: On Fri, 5 Sep 2003, Konstantin KABASSANOV wrote: Hi, I'm actually working on a teredo server/relay implementation as a netgraph node. Can you tell me, please, who I need to contact for an eventual integration of my code into the netgraph source. contact me.. what is teredo? For example this gives you a short summary: http://www.ipv6style.jp/en/building/20030822/20030822_p.shtml Pete Thanks. Konstantin _ Konstantin K. KABASSANOV Research and Development Engineer LIP6 Laboratory Pierre and Marie Curie University 8, rue du Capitaine Scott, 75015 Paris, France Phone: +33 (0) 1 44 27 71 26 Fax: +33 (0) 1 44 27 74 95 E-mail: [EMAIL PROTECTED] Web: http://www.kabassanov.com __ ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]" ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]" ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: adding a teredo node into netgraph
> what is teredo? a security-problematic hack that should not be necessary on an opsys that has other means of running v6 in a v4 world, e.g., faith. randy ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: adding a teredo node into netgraph
Hi, > contact me.. > > what is teredo? I have been working with Konstantin about it. It is an IPv6 over UDP/IPv4 migration service. It is supported by Windows XP + SP1 + Microsoft update. It can be used in order to cross some NATs. see http://www.ietf.org/internet-drafts/draft-huitema-v6ops-teredo-00.txt http://www.microsoft.com/technet/treeview/default.asp?url=/technet/prodtechnol/winxppro/maintain/Teredo.asp Regards, Vincent ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Reserving a couple of names for custom developed netgraph nodes
Like the subjects says, I think it would be nice to reserve a couple of names (like ng_cust1 & ng_cust2) for user developed netgraph nodes (something like unix did with major&minor numbers of device). With a couple of spare nodes it would be possible to develop and test new netgraph nodes without overwriting already existing nodes i.e. ng_tee. What do you think about it? -- Paolo Italian FreeBSD User Group: http://www.gufi.org Join us at GufiCON4 in Pisa: http://www.gufi.org/guficon4/ ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
checksum offload question
In FreeBSD 5 are IP frags guaranteed to be passed to a network driver with no intermediary IP packets between the fragments? Or can multiple streams get queued at once? Specifically, if a driver claims to be able to CSUM_IP_FRAGS, can it count on getting all the frags, one right after another (perhaps with an arp request mixed in for variety)? Thanks, Drew ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
TCP Segmentation Offload
I've been reading a little about TCP Segmentation Offload (aka TSO). We don't appear to support it, but at least 2 of our supported nics (e1000 and bge) apparently could support it. The gist is that TCP pretends the nic has a large mtu, and passes a large (> the mtu on the link layer) packet down to driver and then the nic. The nic then fragments the large packet into smaller (<=mtu) packets. It uses the initial TCP header as a template to construct the headers for the "fragments.". The people who implemented it on linux claim a 50% CPU savings for an Intel 1Gb/s adaptor with a 1500 byte mtu. It seems like it could be implemented rather easily by adding an if_hwassist flag (CSUM_TSO). If this flag is set on the interface found by tcp_mss(), then the mss is set to 56k. This causes TCP to generate huge packets. We then add a check in ip_output() after the (near the existing CSUM_FRAGMENT check) which checks to see if its both a TCP packet, and if CSUM_TSO is set in the if_hwassist flags. If so, the huge packet is passed on down to the driver. Does this sound reasonable? The only other thing I can think of is that some nics might not be able to handle such a large mss, and we might want to stuff the maximum mss value into the ifnet struct. I don't have a bge or an e1000, so I'm not ready to actually implement this. I'm more considering firmware optimizations for our product, and would implement it in a few months, after making the firmware changes. Drew ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Burst Feature
Hi all, I've been doing research recently on traffic shaping/limitting options on several platforms. Since Linux and Cisco has something called "burst" is there anything similar in FreeBSD. If YES - can you point me the docs. Thanks in advance. -- ___ Get your free email from http://mymail.bsdmail.com Powered by Outblaze ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
