Re: bin/145934: [patch] add count option to netstat(1)
Synopsis: [patch] add count option to netstat(1) Responsible-Changed-From-To: freebsd-bugs->freebsd-net Responsible-Changed-By: gavin Responsible-Changed-When: Tue Aug 10 07:32:12 UTC 2010 Responsible-Changed-Why: Over to freebsd-net. The patch attached has been tested by Sterling "Chip" Camden , but I'm not sure if this extra functionality is worth usin one of the remaining command line options on - although as the submitter says, it would bring it in line with several other base system utilities. http://www.freebsd.org/cgi/query-pr.cgi?pr=145934 ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
Re: kern/148112: [ath] Atheros 9285 cannot register with wifi AP (timeout)
Synopsis: [ath] Atheros 9285 cannot register with wifi AP (timeout) Responsible-Changed-From-To: freebsd-net->adrian Responsible-Changed-By: adrian Responsible-Changed-When: Tue Aug 10 07:52:09 UTC 2010 Responsible-Changed-Why: I'll take responsibility for forward porting whatever AR9280/AR9285 work is needed. http://www.freebsd.org/cgi/query-pr.cgi?pr=148112 ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
Re: Server sporadically sending unexpected RST to Client
On 09.08.2010 15:03, Seth Jeacopello wrote:
Thanks for the quick reply Andre; we have some new information.
First I took some time to review some of the tcpdumps per your
recommendation and have not found /any/ reuse (with most dumps spanning
approx. a one hour time frame and the problem occurring toward the end of
the time frame).
OK. I thought this to be the most likely source of the problem.
The client system is another FreeBSD system (we are unsure of the version at
this time).
If there is no port reuse then the client OS shouldn't matter.
You may be correct about the syncache simply showing the symptoms; as we dug
deeper we began looking at changes in netisr, in particular the direct
dispatch policy modifications. We've run some tests over the weekend and
found something that seems to work for us.
We've found that moving from 'Always Direct' to 'Hybrid' mode seems to
resolve the issue for us without any noticed consequences (setting
net.isr.direct_force=0). Can anyone comment on this setting and let us know
of any downsides or problems that may occur running in this mode?
I haven't worked on the netisr code but a quick glance suggest that running
in hybrid mode should be fine and not cause any further problems.
We believe that this problem is also only isolated to one of our Server
platforms (testing on our other platform is still on-going, though initial
results look good).
OK.
Both platforms are Intel based (current generation vs. last generation) with
various differences, though the one that may be most relative is the change
of the on-board NIC from being 'em' based to 'igb' based (that is the
systems with the issue all have 'em' based NICs vs. 'igb' of the newer
systems). This could be red-herring as well, though I feel it's probably a
good idea to include as much information as possible when troubleshooting.
It is unlikely that the network card or the driver has anything to do with it.
Thank you for all of your help and I look forward to hearing any further
thoughts on this issue.
Please try the attached patch so I get better information from syncache_socket
on the particular error that comes up. Socket creation and PCB setup are very
complicated areas.
--
Andre
Index: tcp_syncache.c
===
--- tcp_syncache.c (revision 211131)
+++ tcp_syncache.c (working copy)
@@ -627,6 +627,7 @@
struct inpcb *inp = NULL;
struct socket *so;
struct tcpcb *tp;
+ int error = 0;
char *s;
INP_INFO_WLOCK_ASSERT(&V_tcbinfo);
@@ -675,7 +676,7 @@
}
#endif
inp->inp_lport = sc->sc_inc.inc_lport;
- if (in_pcbinshash(inp) != 0) {
+ if ((error = in_pcbinshash(inp)) != 0) {
/*
* Undo the assignments above if we failed to
* put the PCB on the hash lists.
@@ -687,6 +688,12 @@
#endif
inp->inp_laddr.s_addr = INADDR_ANY;
inp->inp_lport = 0;
+ if ((s = tcp_log_addrs(&sc->sc_inc, NULL, NULL, NULL))) {
+ log(LOG_DEBUG, "%s; %s: in_pcbinshash failed "
+ "with error %i\n",
+ s, __func__, error);
+ free(s, M_TCPLOG);
+ }
goto abort;
}
#ifdef IPSEC
@@ -721,9 +728,15 @@
laddr6 = inp->in6p_laddr;
if (IN6_IS_ADDR_UNSPECIFIED(&inp->in6p_laddr))
inp->in6p_laddr = sc->sc_inc.inc6_laddr;
- if (in6_pcbconnect(inp, (struct sockaddr *)&sin6,
- thread0.td_ucred)) {
+ if ((error = in6_pcbconnect(inp, (struct sockaddr *)&sin6,
+ thread0.td_ucred)) != 0) {
inp->in6p_laddr = laddr6;
+ if ((s = tcp_log_addrs(&sc->sc_inc, NULL, NULL, NULL)))
{
+ log(LOG_DEBUG, "%s; %s: in6_pcbconnect failed "
+ "with error %i\n",
+ s, __func__, error);
+ free(s, M_TCPLOG);
+ }
goto abort;
}
/* Override flowlabel from in6_pcbconnect. */
@@ -750,9 +763,15 @@
laddr = inp->inp_laddr;
if (inp->inp_laddr.s_addr == INADDR_ANY)
inp->inp_laddr = sc->sc_inc.inc_laddr;
- if (in_pcbconnect(inp, (struct sockaddr *)&sin,
- thread0.td_ucred)) {
+ if ((error = in_pcbconnect(inp, (struct sockaddr *)&sin,
+ thread0.td_ucred)) != 0) {
inp->inp_laddr = laddr;
+ if ((s = tcp_log_addrs(&sc->sc_inc, NULL, NULL, NULL)))
{
+ log(LOG_DEBUG, "%s; %s: in_pcbconnect failed "
+ "with error %i\n",
ipv6 route extension header
Hi, While executing conformance test for IPv6 Neighbor Discovery functionality, we saw failures due to non-existing support for IPv6 route extension header in Freebsd V7.2 Code base. Steps for conformance test are described below -: Configuration -: TESTER_A++IUT+TESTER_B 1> tester A and B is sending neighbor solicitation to IUT 2> IUT responds with neighbor advertisements. 3> tester B transit a echo request to tester A via IUT.. 4> Echo request is having routing extension header. 5> IUT is generating ICMP error due to the presence of routing extension header. While looking into the file (netinet6/route6.c),we can see that the code has been commented. Why there is no support for route extension header in freebsd v7.2 ? >From which release we have the code that support route extension header ? Thanks and Regards, Saurav Dasgupta "DISCLAIMER: This message is proprietary to Aricent and is intended solely for the use of the individual to whom it is addressed. It may contain privileged or confidential information and should not be circulated or used for any purpose other than for what it is intended. If you have received this message in error, please notify the originator immediately. If you are not the intended recipient, you are notified that you are strictly prohibited from using, copying, altering, or disclosing the contents of this message. Aricent accepts no responsibility for loss or damage arising from the use of the information transmitted by this email including damage from virus." ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
(no subject)
Hi, While executing conformance test for IPv6 Neighbor Discovery functionality, we saw failures due to non-existing support for IPv6 route extension header in Freebsd V7.2 Code base. Steps for conformance test are described below -: Configuration -: TESTER_A++IUT+TESTER_B 1> tester A and B is sending neighbor solicitation to IUT 2> IUT responds with neighbor advertisements. 3> tester B transit a echo request to tester A via IUT.. 4> Echo request is having routing extension header. 5> IUT is generating ICMP error due to the presence of routing extension header. While looking into the file (netinet6/route6.c),we can see that the code has been commented. Why there is no support for route extension header in freebsd v7.2 ? >From which release we have the code that support route extension header ? Thanks and Regards, Saurav Dasgupta "DISCLAIMER: This message is proprietary to Aricent and is intended solely for the use of the individual to whom it is addressed. It may contain privileged or confidential information and should not be circulated or used for any purpose other than for what it is intended. If you have received this message in error, please notify the originator immediately. If you are not the intended recipient, you are notified that you are strictly prohibited from using, copying, altering, or disclosing the contents of this message. Aricent accepts no responsibility for loss or damage arising from the use of the information transmitted by this email including damage from virus." ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
Re: amd64/149488: SCTP streams not working on AMD64 platform
Synopsis: SCTP streams not working on AMD64 platform Responsible-Changed-From-To: freebsd-amd64->freebsd-net Responsible-Changed-By: brucec Responsible-Changed-When: Tue Aug 10 09:19:47 UTC 2010 Responsible-Changed-Why: Over to maintainer(s). http://www.freebsd.org/cgi/query-pr.cgi?pr=149488 ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
Re: Watchdog resets on 82575
Is there an easy way to check which chip is present as the startup doesnt seem to mention it? igb0: port 0xec00-0xec1f mem 0xfade-0xfadf,0xfadc-0xfadd,0xfad9c000-0xfad9 irq 28 at device 0.0 on pci1 igb0: Using MSIX interrupts with 10 vectors igb0: [ITHREAD] igb0: [ITHREAD] igb0: [ITHREAD] igb0: [ITHREAD] igb0: [ITHREAD] igb0: [ITHREAD] igb0: [ITHREAD] igb0: [ITHREAD] igb0: [ITHREAD] igb0: [ITHREAD] igb0: Ethernet address: 00:25:90:02:63:3a ... Regards Steve - Original Message - From: "Jack Vogel" To: "FreeBSD Net" ; "FreeBSD stable" ; "FreeBSD Current" Sent: Friday, August 06, 2010 10:15 PM Subject: Watchdog resets on 82575 If you have this adapter and have been getting watchdogs you need to pick up the small update I checked into HEAD today. When I added the SR-IOV support for the 82576 adapter I removed a call to set the MAC type in an early routine, thinking it was unnecessary, since a slightly later shared code init does the same thing. I also saw no problem when I did this on the 82576 well, it did have a bad effect that I did not notice, the slightly later call, igb_setup_msix() did not have the mac set and this resulted in the 82575 creating more queues than it is really able to handle. So, bottom line, this is a critical fix for 82575: SVN rev 210968 Cheers, Jack ___ freebsd-sta...@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org" This e.mail is private and confidential between Multiplay (UK) Ltd. and the person or entity to whom it is addressed. In the event of misdirection, the recipient is prohibited from using, copying, printing or otherwise disseminating it or any information contained in it. In the event of misdirection, illegible or incomplete transmission please telephone +44 845 868 1337 or return the E.mail to postmas...@multiplay.co.uk. ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
Re: amd64/149488: SCTP streams not working on AMD64 platform
Dear all,
it is not a problem in the kernel. The application does not handle
the cmsg stuff correctly in send_on_stream().
Using
/* Send a message on a socket and a particular stream */
void send_on_stream(int sock, unsigned int strid, unsigned char * msg, size_t
sz)
{
struct msghdr mhdr;
struct iovec iov;
struct cmsghdr *cmsg;
struct sctp_sndrcvinfo *info;
char buffer[CMSG_SPACE(sizeof(struct sctp_sndrcvinfo))];
ssize_t ret;
memset(&mhdr, 0, sizeof(mhdr));
memset(&iov, 0, sizeof(iov));
memset(buffer, 0, CMSG_SPACE(sizeof(struct sctp_sndrcvinfo)));
/* IO Vector: message data */
iov.iov_base = msg;
iov.iov_len = sz;
/* Anciliary data: specify SCTP stream */
cmsg = (struct cmsghdr *)buffer;
cmsg->cmsg_level = IPPROTO_SCTP;
cmsg->cmsg_type = SCTP_SNDRCV;
cmsg->cmsg_len = CMSG_LEN(sizeof(struct sctp_sndrcvinfo));
info = (struct sctp_sndrcvinfo *)CMSG_DATA(cmsg);
info->sinfo_stream = strid;
mhdr.msg_iov= &iov;
mhdr.msg_iovlen = 1;
mhdr.msg_control= buffer;
mhdr.msg_controllen = cmsg->cmsg_len;
if ( (ret = sendmsg(sock, &mhdr, 0)) < 0) {
perror("sendmsg");
exit (1);
}
ASSERT( ret == sz ); /* There should not be partial delivery with
sendmsg... */
return;
}
solves the problem.
Best regards
Michael
On Aug 10, 2010, at 11:20 AM, bru...@freebsd.org wrote:
> Synopsis: SCTP streams not working on AMD64 platform
>
> Responsible-Changed-From-To: freebsd-amd64->freebsd-net
> Responsible-Changed-By: brucec
> Responsible-Changed-When: Tue Aug 10 09:19:47 UTC 2010
> Responsible-Changed-Why:
> Over to maintainer(s).
>
> http://www.freebsd.org/cgi/query-pr.cgi?pr=149488
> ___
> freebsd-net@freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-net
> To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
>
___
freebsd-net@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
Re: Watchdog resets on 82575
On Tue, Aug 10, 2010 at 10:30:21AM +0100, Steven Hartland wrote: > Is there an easy way to check which chip is present as the startup doesnt > seem to mention it? Not during start-up, but once the machine is running (including in single-user), you can do: pciconf -lvc And look for device igb0. -- | Jeremy Chadwick j...@parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. PGP: 4BD6C0CB | ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
Re: Watchdog resets on 82575
Thanks Jeremy, from that we get:- i...@pci0:1:0:0:class=0x02 card=0x060015d9 chip=0x10c98086 rev=0x01 hdr=0x00 vendor = 'Intel Corporation' class = network subclass = ethernet cap 01[40] = powerspec 3 supports D0 D3 current D0 cap 05[50] = MSI supports 1 message, 64 bit, vector masks cap 11[70] = MSI-X supports 10 messages in map 0x1c enabled cap 10[a0] = PCI-Express 2 endpoint max data 256(512) link x4(x4) i...@pci0:1:0:1:class=0x02 card=0x060015d9 chip=0x10c98086 rev=0x01 hdr=0x00 vendor = 'Intel Corporation' class = network subclass = ethernet cap 01[40] = powerspec 3 supports D0 D3 current D0 cap 05[50] = MSI supports 1 message, 64 bit, vector masks cap 11[70] = MSI-X supports 10 messages in map 0x1c enabled cap 10[a0] = PCI-Express 2 endpoint max data 256(512) link x4(x4) I assume there is a way to convert from the hex values to the human value but not sure what it is? Regards Steve - Original Message - From: "Jeremy Chadwick" To: "Steven Hartland" Cc: "Jack Vogel" ; "FreeBSD Net" ; "FreeBSD stable" ; "FreeBSD Current" Sent: Tuesday, August 10, 2010 11:04 AM Subject: Re: Watchdog resets on 82575 On Tue, Aug 10, 2010 at 10:30:21AM +0100, Steven Hartland wrote: Is there an easy way to check which chip is present as the startup doesnt seem to mention it? Not during start-up, but once the machine is running (including in single-user), you can do: pciconf -lvc And look for device igb0. -- | Jeremy Chadwick j...@parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. PGP: 4BD6C0CB | This e.mail is private and confidential between Multiplay (UK) Ltd. and the person or entity to whom it is addressed. In the event of misdirection, the recipient is prohibited from using, copying, printing or otherwise disseminating it or any information contained in it. In the event of misdirection, illegible or incomplete transmission please telephone +44 845 868 1337 or return the E.mail to postmas...@multiplay.co.uk. ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
Re: Watchdog resets on 82575
Steven Hartland wrote: > Thanks Jeremy, from that we get:- > > i...@pci0:1:0:0:class=0x02 card=0x060015d9 chip=0x10c98086 > rev=0x01 hdr=0x00 > i...@pci0:1:0:1:class=0x02 card=0x060015d9 chip=0x10c98086 > rev=0x01 hdr=0x00 The important thing is the "chip" ID: 0x10c98086 The lower half is the vendor ID: 8086 is intel. The upper half is the device ID: 10c9 is the 82576 gigabit NIC. You can look up these numbers on http://pciids.sf.net for example. Best regards Oliver -- Oliver Fromme, secnetix GmbH & Co. KG, Marktplatz 29, 85567 Grafing b. M. Handelsregister: Registergericht Muenchen, HRA 74606, Geschäftsfuehrung: secnetix Verwaltungsgesellsch. mbH, Handelsregister: Registergericht Mün- chen, HRB 125758, Geschäftsführer: Maik Bachmann, Olaf Erb, Ralf Gebhart FreeBSD-Dienstleistungen, -Produkte und mehr: http://www.secnetix.de/bsd "Life is short (You need Python)" -- Bruce Eckel, ANSI C++ Comitee member, author of "Thinking in C++" and "Thinking in Java" ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
Re: Watchdog resets on 82575
On Tue, Aug 10, 2010 at 11:23:26AM +0100, Steven Hartland wrote: > Thanks Jeremy, from that we get:- > > i...@pci0:1:0:0:class=0x02 card=0x060015d9 chip=0x10c98086 > rev=0x01 hdr=0x00 >vendor = 'Intel Corporation' >class = network >subclass = ethernet >cap 01[40] = powerspec 3 supports D0 D3 current D0 >cap 05[50] = MSI supports 1 message, 64 bit, vector masks >cap 11[70] = MSI-X supports 10 messages in map 0x1c enabled >cap 10[a0] = PCI-Express 2 endpoint max data 256(512) link x4(x4) > i...@pci0:1:0:1:class=0x02 card=0x060015d9 chip=0x10c98086 > rev=0x01 hdr=0x00 >vendor = 'Intel Corporation' >class = network >subclass = ethernet >cap 01[40] = powerspec 3 supports D0 D3 current D0 >cap 05[50] = MSI supports 1 message, 64 bit, vector masks >cap 11[70] = MSI-X supports 10 messages in map 0x1c enabled >cap 10[a0] = PCI-Express 2 endpoint max data 256(512) link x4(x4) > > I assume there is a way to convert from the hex values to the human value > but not sure what it is? The "card" and "chip" identifiers are part of the PCI ID specification. You can see what the "human value" is by examining the source code for the driver. Sometimes it's easy to figure out, other times there's a series of #define's which you have to reverse engineer. In this case, there's two places with relevant information: src/sys/dev/e1000/if_igb.c src/sys/dev/e1000/e1000_hw.h You have to split the Chip ID into two separate 16-bit portions, so 0x10c9 and 0x8086. 0x8086 is Intel's vendor code. 0x10c9 is the device ID of the individual NIC/model type. So: $ grep -i 0x10c9 * e1000_hw.h:#define E1000_DEV_ID_825760x10C9 For Jack: igb_vendor_info_array should really be extended to include actual ASCII strings for the individual chips/models/codenames. I'm sure that's on your todo list somewhere. I'd be willing to write this but would need a list of the models (or maybe the Linux driver has them in comments, etc. and I could go off of that). -- | Jeremy Chadwick j...@parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. PGP: 4BD6C0CB | ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
"RX ring hdr initialization error"
Hi I've bought a asus M4a78-EM Motherboard. to build a NAS on, thinking the onboard Realtek would be sufficant speed unfortunatly the onboard fives 16/31 mbs at best ps later It improved with enabeling "polling" in the kernel (duh) so I had a PCI intel GT nic around, what gave intermittent tcp/ip connections in a other machine (ESXi) unfortunatly this was the same with Freebsd (card issue?) The card is still in the machine even with the Intel supplied BSD driver now I bought a PCIe intel CT nic, put it in and the kernel panic with "RX ring hdr initialization error" so replaced the intel with the freebsd one by doing intel overwrites the freebsd one /boot/kernel/if_em.ko # cd /usr/src/sys/modules/em/ && make obj depend all install (was already in the kernel) still panic anybody got some idea's howto fix ? # pciconf -lv gives hos...@pci0:0:0:0: class=0x06 card=0x82f11043 chip=0x96001022 rev=0x00 hdr=0x00 vendor = 'Advanced Micro Devices (AMD)' class = bridge subclass = HOST-PCI pc...@pci0:0:1:0: class=0x060400 card=0x82f11043 chip=0x96021043 rev=0x00 hdr=0x01 vendor = 'Asustek Computer Inc.' class = bridge subclass = PCI-PCI pc...@pci0:0:9:0: class=0x060400 card=0x82f11043 chip=0x96081022 rev=0x00 hdr=0x01 vendor = 'Advanced Micro Devices (AMD)' class = bridge subclass = PCI-PCI pc...@pci0:0:10:0: class=0x060400 card=0x82f11043 chip=0x96091022 rev=0x00 hdr=0x01 vendor = 'Advanced Micro Devices (AMD)' class = bridge subclass = PCI-PCI ah...@pci0:0:17:0: class=0x010601 card=0x82ef1043 chip=0x43911002 rev=0x00 hdr=0x00 vendor = 'ATI Technologies Inc. / Advanced Micro Devices, Inc.' device = 'SB700 SATA Controller [AHCI mode]' class = mass storage subclass = SATA oh...@pci0:0:18:0: class=0x0c0310 card=0x82ef1043 chip=0x43971002 rev=0x00 hdr=0x00 vendor = 'ATI Technologies Inc. / Advanced Micro Devices, Inc.' device = 'SB700 USB OHCI0 Controller' class = serial bus subclass = USB oh...@pci0:0:18:1: class=0x0c0310 card=0x82ef1043 chip=0x43981002 rev=0x00 hdr=0x00 vendor = 'ATI Technologies Inc. / Advanced Micro Devices, Inc.' device = 'Standard OpenHCD USB-Hostcontroller (SB700)' class = serial bus subclass = USB eh...@pci0:0:18:2: class=0x0c0320 card=0x82ef1043 chip=0x43961002 rev=0x00 hdr=0x00 vendor = 'ATI Technologies Inc. / Advanced Micro Devices, Inc.' device = 'SB700 USB EHCI Controller' class = serial bus subclass = USB oh...@pci0:0:19:0: class=0x0c0310 card=0x82ef1043 chip=0x43971002 rev=0x00 hdr=0x00 vendor = 'ATI Technologies Inc. / Advanced Micro Devices, Inc.' device = 'SB700 USB OHCI0 Controller' class = serial bus subclass = USB oh...@pci0:0:19:1: class=0x0c0310 card=0x82ef1043 chip=0x43981002 rev=0x00 hdr=0x00 vendor = 'ATI Technologies Inc. / Advanced Micro Devices, Inc.' device = 'Standard OpenHCD USB-Hostcontroller (SB700)' class = serial bus subclass = USB eh...@pci0:0:19:2: class=0x0c0320 card=0x82ef1043 chip=0x43961002 rev=0x00 hdr=0x00 vendor = 'ATI Technologies Inc. / Advanced Micro Devices, Inc.' device = 'SB700 USB EHCI Controller' class = serial bus subclass = USB no...@pci0:0:20:0: class=0x0c0500 card=0x82ef1043 chip=0x43851002 rev=0x3a hdr=0x00 vendor = 'ATI Technologies Inc. / Advanced Micro Devices, Inc.' device = 'ATI SMBus (ATI RD600/RS600)' class = serial bus subclass = SMBus atap...@pci0:0:20:1:class=0x01018a card=0x82ef1043 chip=0x439c1002 rev=0x00 hdr=0x00 vendor = 'ATI Technologies Inc. / Advanced Micro Devices, Inc.' device = 'PATA 133 Controller (SB7xx)' class = mass storage subclass = ATA is...@pci0:0:20:3: class=0x060100 card=0x82ef1043 chip=0x439d1002 rev=0x00 hdr=0x00 vendor = 'ATI Technologies Inc. / Advanced Micro Devices, Inc.' device = 'SB700 LPC host controller' class = bridge subclass = PCI-ISA pc...@pci0:0:20:4: class=0x060401 card=0x chip=0x43841002 rev=0x00 hdr=0x01 vendor = 'ATI Technologies Inc. / Advanced Micro Devices, Inc.' device = 'IXP SB600 PCI to PCI Bridge' class = bridge subclass = PCI-PCI oh...@pci0:0:20:5: class=0x0c0310 card=0x82ef1043 chip=0x43991002 rev=0x00 hdr=0x00 vendor = 'ATI Technologies Inc. / Advanced Micro Devices, Inc.' device = 'SB700 USB OHCI2 Controller' class = serial bus subclass = USB hos...@pci0:0:24:0: class=0x06 card=0x chip=0x11001022 rev=0x00 hdr=0x00 vendor = 'Advanced Mi
RE: Server sporadically sending unexpected RST to Client
Interestingly the patch you provided is almost identical to what we put in place on the system to trace the issue earlier. Without having merged the patch yet, let me give you what we do have from that run: Aug 6 11:15:27 kernel: Entering syncache_add Aug 6 11:15:27 kernel: Entering syncache_expand Aug 6 11:15:27 kernel: TCP: [10.174.50.35]:52872 to [10.174.80.242]:389 tcpflags 0x18; syncache_expand: Just before syncache_socket() Aug 6 11:15:27 kernel: Entering syncache_socket Aug 6 11:15:27 kernel: Entering syncache_expand Aug 6 11:15:27 kernel: TCP: [10.174.50.35]:52872 to [10.174.80.242]:389 tcpflags 0x10; syncache_expand: Just before syncache_socket() Aug 6 11:15:27 kernel: Entering syncache_socket Aug 6 11:15:27 kernel: TCP: [10.174.50.35]:52872 to [10.174.80.242]:389; syncache_socket: Socket create failed in_pcbconnect: 48 Aug 6 11:15:27 kernel: TCP: [10.174.50.35]:52872 to [10.174.80.242]:389 tcpflags 0x10; tcp_input: Listen socket: Socket allocation failed due to limits or memory shortage, sending RST Also, I wanted to note again that the tcpdumps we've grabbed are showing that the packets are going across the wire in order, however, debug logging of the issue on the Server side has shown they appear to be processed out of order (with the PSH, ACK being processed before the final ACK of the handshake). --Seth ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
Re: amd64/149488: SCTP streams not working on AMD64 platform
Synopsis: SCTP streams not working on AMD64 platform State-Changed-From-To: open->closed State-Changed-By: brucec State-Changed-When: Tue Aug 10 18:56:10 UTC 2010 State-Changed-Why: Not a problem with FreeBSD. http://www.freebsd.org/cgi/query-pr.cgi?pr=149488 ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
Re: Watchdog resets on 82575
On Tue, Aug 10, 2010 at 03:57:22AM -0700, Jeremy Chadwick wrote: > On Tue, Aug 10, 2010 at 11:23:26AM +0100, Steven Hartland wrote: > > Thanks Jeremy, from that we get:- > > > > i...@pci0:1:0:0:class=0x02 card=0x060015d9 chip=0x10c98086 > > rev=0x01 hdr=0x00 > >vendor = 'Intel Corporation' > >class = network > >subclass = ethernet > >cap 01[40] = powerspec 3 supports D0 D3 current D0 > >cap 05[50] = MSI supports 1 message, 64 bit, vector masks > >cap 11[70] = MSI-X supports 10 messages in map 0x1c enabled > >cap 10[a0] = PCI-Express 2 endpoint max data 256(512) link x4(x4) > > i...@pci0:1:0:1:class=0x02 card=0x060015d9 chip=0x10c98086 > > rev=0x01 hdr=0x00 > >vendor = 'Intel Corporation' > >class = network > >subclass = ethernet > >cap 01[40] = powerspec 3 supports D0 D3 current D0 > >cap 05[50] = MSI supports 1 message, 64 bit, vector masks > >cap 11[70] = MSI-X supports 10 messages in map 0x1c enabled > >cap 10[a0] = PCI-Express 2 endpoint max data 256(512) link x4(x4) > > > > I assume there is a way to convert from the hex values to the human value > > but not sure what it is? > > The "card" and "chip" identifiers are part of the PCI ID specification. > You can see what the "human value" is by examining the source code for > the driver. Sometimes it's easy to figure out, other times there's a > series of #define's which you have to reverse engineer. > > In this case, there's two places with relevant information: > > src/sys/dev/e1000/if_igb.c > src/sys/dev/e1000/e1000_hw.h > > You have to split the Chip ID into two separate 16-bit portions, so > 0x10c9 and 0x8086. > > 0x8086 is Intel's vendor code. 0x10c9 is the device ID of the > individual NIC/model type. So: > > $ grep -i 0x10c9 * > e1000_hw.h:#define E1000_DEV_ID_825760x10C9 > > For Jack: igb_vendor_info_array should really be extended to include > actual ASCII strings for the individual chips/models/codenames. I'm > sure that's on your todo list somewhere. I'd be willing to write this > but would need a list of the models (or maybe the Linux driver has them > in comments, etc. and I could go off of that). > I guess em(4)/igb(4)/ixgb(4)/ixgbe(4) only shows vendor string and driver version which effectively hides controller name/model details in device attach phase. Personally I like to see more detailed controller model information which may help narrowing down affected lits of controllers when an issue is reported. Currently we have to get this information by requesting the output of pciconf(4) which in turn requires one more round trip of mail. ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
Re: "RX ring hdr initialization error"
On Tue, Aug 10, 2010 at 12:52:56PM +0200, Victor Ophof wrote:
>
>
>
>
> Hi
>
> I've bought a asus M4a78-EM Motherboard. to build a NAS on,
> thinking the onboard Realtek would be sufficant speed
> unfortunatly the onboard fives 16/31 mbs at best
>
> ps later It improved with enabeling "polling" in the kernel (duh)
>
> so I had a PCI intel GT nic around, what gave intermittent tcp/ip connections
> in a other machine (ESXi)
> unfortunatly this was the same with Freebsd (card issue?) The card is still
> in the machine
> even with the Intel supplied BSD driver
>
> now I bought a PCIe intel CT nic, put it in and the kernel panic with
> "RX ring hdr initialization error"
> so replaced the intel with the freebsd one by doing
> intel overwrites the freebsd one /boot/kernel/if_em.ko
> # cd /usr/src/sys/modules/em/ && make obj depend all install
> (was already in the kernel)
>
>
> still panic
> anybody got some idea's howto fix ?
>
I have been using the attached patch for em(4)/igb(4) controllers.
These drivers explicitly calls panic(9) when memory allocation
failure happens. I don't think it's good idea to panic the box
under resource shortage condition as it's common to see this
situation on heavily loaded servers.
The patch does not solve the one issue yet. The panic caused by
RX buffer allocation failure condition which in turn means you're
allocating a lot of buffers. Reduce number of descriptors if you
increased that too high and see whether the issue could be gone.
Index: sys/dev/e1000/if_igb.c
===
--- sys/dev/e1000/if_igb.c (revision 211102)
+++ sys/dev/e1000/if_igb.c (working copy)
@@ -178,7 +178,7 @@
static void igb_free_pci_resources(struct adapter *);
static void igb_local_timer(void *);
static void igb_reset(struct adapter *);
-static void igb_setup_interface(device_t, struct adapter *);
+static int igb_setup_interface(device_t, struct adapter *);
static int igb_allocate_queues(struct adapter *);
static void igb_configure_queues(struct adapter *);
@@ -559,7 +559,8 @@
goto err_late;
/* Setup OS specific network interface */
- igb_setup_interface(dev, adapter);
+ if (igb_setup_interface(dev, adapter) != 0)
+ goto err_late;
/* Now get a good starting state */
igb_reset(adapter);
@@ -608,6 +609,8 @@
igb_free_transmit_structures(adapter);
igb_free_receive_structures(adapter);
igb_release_hw_control(adapter);
+ if (adapter->ifp != NULL)
+ if_free(adapter->ifp);
err_pci:
igb_free_pci_resources(adapter);
IGB_CORE_LOCK_DESTROY(adapter);
@@ -2653,7 +2656,7 @@
* Setup networking device structure and register an interface.
*
**/
-static void
+static int
igb_setup_interface(device_t dev, struct adapter *adapter)
{
struct ifnet *ifp;
@@ -2661,8 +2664,10 @@
INIT_DEBUGOUT("igb_setup_interface: begin");
ifp = adapter->ifp = if_alloc(IFT_ETHER);
- if (ifp == NULL)
- panic("%s: can not if_alloc()", device_get_nameunit(dev));
+ if (ifp == NULL) {
+ device_printf(dev, "can not allocate ifnet structure\n");
+ return (-1);
+ }
if_initname(ifp, device_get_name(dev), device_get_unit(dev));
ifp->if_mtu = ETHERMTU;
ifp->if_init = igb_init;
@@ -2739,6 +2744,7 @@
}
ifmedia_add(&adapter->media, IFM_ETHER | IFM_AUTO, 0, NULL);
ifmedia_set(&adapter->media, IFM_ETHER | IFM_AUTO);
+ return (0);
}
Index: sys/dev/e1000/if_lem.c
===
--- sys/dev/e1000/if_lem.c (revision 211102)
+++ sys/dev/e1000/if_lem.c (working copy)
@@ -186,7 +186,7 @@
static void lem_free_pci_resources(struct adapter *);
static void lem_local_timer(void *);
static int lem_hardware_init(struct adapter *);
-static void lem_setup_interface(device_t, struct adapter *);
+static int lem_setup_interface(device_t, struct adapter *);
static void lem_setup_transmit_structures(struct adapter *);
static void lem_initialize_transmit_unit(struct adapter *);
static int lem_setup_receive_structures(struct adapter *);
@@ -620,7 +620,8 @@
lem_get_wakeup(dev);
/* Setup OS specific network interface */
- lem_setup_interface(dev, adapter);
+ if (lem_setup_interface(dev, adapter) != 0)
+ goto err_rx_struct;
/* Initialize statistics */
lem_update_stats_counters(adapter);
@@ -672,6 +673,8 @@
lem_dma_free(adapter, &adapter->txdma);
err_tx_desc:
err_pci:
+ if (adapter->ifp != NULL)
+ if_free(adapter->ifp);
lem_free_pci_resources(adapter);
EM_TX_LOCK_DESTROY(adapter);
EM_RX_LOCK_DESTROY(adapter);
@@ -1939,6 +1942,19 @@
IOCTL_DEBUGOUT("lem_set_multi: begin");
+ /*
+ * Allocate temporary memory to setup array. If there is not
+ * enough resource, give up setting multicast filter.
+ */
+ mta = malloc(sizeof(u8) *
+ (ETH_ADDR_LEN * MAX_NUM_MULTICAST_ADDRESSES),
+ M_DEVBUF, M_NOWAIT | M_ZERO);
+ if (mta == NULL) {
+ device_printf(adapter->dev,
+ "can no
Re: kern/146628: [tcp] [patch] TCP does not clear DF when MTU is below a threshold
Synopsis: [tcp] [patch] TCP does not clear DF when MTU is below a threshold Responsible-Changed-From-To: freebsd-net->andre Responsible-Changed-By: andre Responsible-Changed-When: Tue Aug 10 22:08:02 UTC 2010 Responsible-Changed-Why: Take over. http://www.freebsd.org/cgi/query-pr.cgi?pr=146628 ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
Re: kern/147352: [netinet] [patch] replace printf() with log() for "Limiting ..."
Synopsis: [netinet] [patch] replace printf() with log() for "Limiting ..." Responsible-Changed-From-To: freebsd-net->andre Responsible-Changed-By: andre Responsible-Changed-When: Tue Aug 10 22:09:49 UTC 2010 Responsible-Changed-Why: Take over. http://www.freebsd.org/cgi/query-pr.cgi?pr=147352 ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
Re: kern/144000: [tcp] setting TCP_MAXSEG by setsockopt() does not seem to have any effect
Synopsis: [tcp] setting TCP_MAXSEG by setsockopt() does not seem to have any effect Responsible-Changed-From-To: freebsd-net->andre Responsible-Changed-By: andre Responsible-Changed-When: Tue Aug 10 22:11:32 UTC 2010 Responsible-Changed-Why: Take over. http://www.freebsd.org/cgi/query-pr.cgi?pr=144000 ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
Re: kern/141314: Network Performance has decreased by 30% [regression]
Synopsis: Network Performance has decreased by 30% [regression] Responsible-Changed-From-To: freebsd-net->andre Responsible-Changed-By: andre Responsible-Changed-When: Tue Aug 10 22:13:52 UTC 2010 Responsible-Changed-Why: Take over. http://www.freebsd.org/cgi/query-pr.cgi?pr=141314 ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
Re: kern/140597: [netinet] [patch] implement Lost Retransmission Detection
Synopsis: [netinet] [patch] implement Lost Retransmission Detection Responsible-Changed-From-To: freebsd-net->andre Responsible-Changed-By: andre Responsible-Changed-When: Tue Aug 10 22:15:15 UTC 2010 Responsible-Changed-Why: Take over. http://www.freebsd.org/cgi/query-pr.cgi?pr=140597 ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
Re: kern/138652: [tcp] TCP window scaling value calculated incorrectly?
Synopsis: [tcp] TCP window scaling value calculated incorrectly? Responsible-Changed-From-To: freebsd-net->andre Responsible-Changed-By: andre Responsible-Changed-When: Tue Aug 10 22:17:20 UTC 2010 Responsible-Changed-Why: Take over. http://www.freebsd.org/cgi/query-pr.cgi?pr=138652 ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
Re: kern/138046: [tcp] tcp sockets stay in SYN_SENT even after receiving RST. never time out as well.
Synopsis: [tcp] tcp sockets stay in SYN_SENT even after receiving RST. never time out as well. Responsible-Changed-From-To: freebsd-net->andre Responsible-Changed-By: andre Responsible-Changed-When: Tue Aug 10 22:18:15 UTC 2010 Responsible-Changed-Why: Take over. http://www.freebsd.org/cgi/query-pr.cgi?pr=138046 ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
Re: kern/137145: [mbuf] [patch] Reference count computing isn't correct when more than one threads call function m_copypacket
Synopsis: [mbuf] [patch] Reference count computing isn't correct when more than one threads call function m_copypacket Responsible-Changed-From-To: freebsd-net->andre Responsible-Changed-By: andre Responsible-Changed-When: Tue Aug 10 22:19:13 UTC 2010 Responsible-Changed-Why: Take over. http://www.freebsd.org/cgi/query-pr.cgi?pr=137145 ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
Re: kern/137317: [tcp] logs full of syncache problems
Synopsis: [tcp] logs full of syncache problems Responsible-Changed-From-To: freebsd-net->andre Responsible-Changed-By: andre Responsible-Changed-When: Tue Aug 10 22:20:02 UTC 2010 Responsible-Changed-Why: Take over. http://www.freebsd.org/cgi/query-pr.cgi?pr=137317 ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
Re: kern/133786: [netinet] [patch] ip_input might cause kernel panic
Synopsis: [netinet] [patch] ip_input might cause kernel panic Responsible-Changed-From-To: freebsd-net->andre Responsible-Changed-By: andre Responsible-Changed-When: Tue Aug 10 22:21:07 UTC 2010 Responsible-Changed-Why: Take over. http://www.freebsd.org/cgi/query-pr.cgi?pr=133786 ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
Re: kern/132832: [netinet] [patch] tcp_output() might generate invalid TSO frames when len > TCP_MAXWIN - hdrlen - optlen
Synopsis: [netinet] [patch] tcp_output() might generate invalid TSO frames when len > TCP_MAXWIN - hdrlen - optlen Responsible-Changed-From-To: freebsd-net->andre Responsible-Changed-By: andre Responsible-Changed-When: Tue Aug 10 22:22:47 UTC 2010 Responsible-Changed-Why: Take over. http://www.freebsd.org/cgi/query-pr.cgi?pr=132832 ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
Re: kern/131536: [netinet] [patch] kernel does allow manipulation of subnet routes
Synopsis: [netinet] [patch] kernel does allow manipulation of subnet routes Responsible-Changed-From-To: freebsd-net->andre Responsible-Changed-By: andre Responsible-Changed-When: Tue Aug 10 22:24:08 UTC 2010 Responsible-Changed-Why: Take over. http://www.freebsd.org/cgi/query-pr.cgi?pr=131536 ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
Re: kern/127928: [tcp] [patch] TCP bandwidth gets squeezed every time tcp_xmit_bandwidth_limit() kicks in
Synopsis: [tcp] [patch] TCP bandwidth gets squeezed every time tcp_xmit_bandwidth_limit() kicks in Responsible-Changed-From-To: freebsd-net->andre Responsible-Changed-By: andre Responsible-Changed-When: Tue Aug 10 22:25:14 UTC 2010 Responsible-Changed-Why: Take over. http://www.freebsd.org/cgi/query-pr.cgi?pr=127928 ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
FreeBSD SCTP support?
Hello, I am encountering a problem with SCTP stack in FreeBSD 8.1 release (on amd64); and I am looking for the correct place to report a bug. Would someone from this list be kind enough to give me direction where I should report the problem? I am totally new to FreeBSD and I was not able to find a better place than this mailing-list so far... If by any change this list is the correct place, you can find the description of the problem and steps to reproduce here: http://www.freebsd.org/cgi/query-pr.cgi?pr=149488 As I understand the answer in that bug report, SCTP is not part of FreeBSD? But I did not install anything special, nor could find a dedicated place on the Internet so far... Thank you! Best regards, Sebastien. -- Sebastien Decugis Research fellow Network Architecture Group NICT (nict.go.jp) ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
Re: FreeBSD SCTP support?
On Aug 11, 2010, at 3:40 AM, Sebastien Decugis wrote:
> Hello,
>
> I am encountering a problem with SCTP stack in FreeBSD 8.1 release (on
> amd64); and I am looking for the correct place to report a bug. Would
> someone from this list be kind enough to give me direction where I
> should report the problem? I am totally new to FreeBSD and I was not
> able to find a better place than this mailing-list so far...
Reporting it here is the correct place.
>
> If by any change this list is the correct place, you can find the
> description of the problem and steps to reproduce here:
> http://www.freebsd.org/cgi/query-pr.cgi?pr=149488
It was reported here yesterday and I responded already...
>
> As I understand the answer in that bug report, SCTP is not part of
> FreeBSD? But I did not install anything special, nor could find a
> dedicated place on the Internet so far...
SCTP is part of FreeBSD. But the point is that your problem is not
related to a bug in FreeBSD but in your application. If you use
/* Send a message on a socket and a particular stream */
void send_on_stream(int sock, unsigned int strid, unsigned char * msg, size_t
sz)
{
struct msghdr mhdr;
struct iovec iov;
struct cmsghdr *cmsg;
struct sctp_sndrcvinfo *info;
char buffer[CMSG_SPACE(sizeof(struct sctp_sndrcvinfo))];
ssize_t ret;
memset(&mhdr, 0, sizeof(mhdr));
memset(&iov, 0, sizeof(iov));
memset(buffer, 0, CMSG_SPACE(sizeof(struct sctp_sndrcvinfo)));
/* IO Vector: message data */
iov.iov_base = msg;
iov.iov_len = sz;
/* Anciliary data: specify SCTP stream */
cmsg = (struct cmsghdr *)buffer;
cmsg->cmsg_level = IPPROTO_SCTP;
cmsg->cmsg_type = SCTP_SNDRCV;
cmsg->cmsg_len = CMSG_LEN(sizeof(struct sctp_sndrcvinfo));
info = (struct sctp_sndrcvinfo *)CMSG_DATA(cmsg);
info->sinfo_stream = strid;
mhdr.msg_iov= &iov;
mhdr.msg_iovlen = 1;
mhdr.msg_control= buffer;
mhdr.msg_controllen = cmsg->cmsg_len;
if ( (ret = sendmsg(sock, &mhdr, 0)) < 0) {
perror("sendmsg");
exit (1);
}
ASSERT( ret == sz ); /* There should not be partial delivery with
sendmsg... */
return;
}
the problem is solved. You were not using the CMSG stuff correctly, so on
64-bit platforms the problem showed up.
I hope this helps, if not, feel free to ask any question or contact me directly.
BTW: Do you have a running implementation of RFC 3436 which supports multiple
streams?
Best regards
Michael
>
> Thank you!
> Best regards,
> Sebastien.
>
> --
> Sebastien Decugis
> Research fellow
> Network Architecture Group
> NICT (nict.go.jp)
>
> ___
> freebsd-net@freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-net
> To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
>
___
freebsd-net@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
Re: FreeBSD SCTP support?
Hello Michael, Thank you for your answer! And many thanks also to all people who anwered to me privately. > SCTP is part of FreeBSD. But the point is that your problem is not > related to a bug in FreeBSD but in your application. Oh, I am sorry, I misinterpreted the answer in the bug report; now I get it! > I hope this helps, if not, feel free to ask any question or contact me > directly. It does!!! Thank you very much. > BTW: Do you have a running implementation of RFC 3436 which supports multiple > streams? Yes, freeDiameter is using it (www.freediameter.net). Feel free to contact me if you need additional information. Best regards, Sebastien. -- Sebastien Decugis Research fellow Network Architecture Group NICT (nict.go.jp) ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
