Re: ESP Raw Socket: Returned IP packet incorrect
On Jul 11, 2011, at 5:26 PM, Matthew Cini Sarreo wrote: > Hello all; > > I have recently encountered a problem when using raw sockets on FreeBSD 8 > (8.0-RELEASE) when using ESP raw sockets. > > I have created a raw esp socket using: > socket(AF_INET, SOCK_RAW, 50); > which works fine. However, when there is a packet on the socket, recvfrom() > returns a packet where the length bytes in the IP header are incorrect; they > are swapped (MSB is placed in the LSB and vice-versa) > > tcpdump shows the following: > > tcpdump: listening on le0, link-type EN10MB (Ethernet), capture size 96 > bytes > 15:00:53.993810 IP (tos 0x0, ttl 64, id 0, offset 0, flags [DF], proto ESP > (50), length 120) >10.0.251.228 > 10.0.252.231: ESP(spi=0xa0534f17,seq=0x3), length 100 >0x: 4500 0078 4000 4032 2d88 0a00 fbe4 >0x0010: 0a00 fce7 a053 4f17 0003 6885 8abd >0x0020: 5ded 44dc 842f 3081 8fa3 bde4 2265 >0x0030: 7438 2bf4 049c 664b 7dc4 44ef 1f6f 5e7d >0x0040: b8c1 482f 8c3b f488 a19a 3d9a d5fe ed9d >0x0050: b1c2 > > > However, recvfrom() returns the following buffer: > 4500 6400 0040 4032 2D88 0A00 FBE4 > 0A00 FCE7 A053 4F17 0003 6885 8ABD > 5DED 44DC 842F 3081 8FA3 BDE4 2265 > 7438 2BF4 049C 664B 7DC4 44EF 1F6F 5E7D > B8C1 482F 8C3B F488 A19A 3D9A D5FE ED9D > B1C2 > > As it is easy to see, the length is not correct (bytes 2 and 3 are 0x6400 > instead of 0x0064) and it does not correspond to the value returned by > recvfrom(). > > Is this a known issue? Am I missing some options for raw sockets that are > required for FreeBSD? I have attempted this on a socket to a TUN interface > (not with an ESP socket) and the buffer had the proper length; it seems to > only happen with ESP. This code runs fine on multiple Linux distributions > and on Windows; it was only noticed with FreeBSD. Could it be that there is > some other ESP application running and interfering (I have not installed > any; don't know if there are by default and I'm quite new to any of the > BSDs)? I think Linux provides the tot_len field in network byte order whereas FreeBSD provides it in host byte order. At least they expect it that way when using a send call. So you must take care of this in the source code of the application by using an #ifdef... Best regards Michael > > Any help would be much appreciated. > Matt > ___ > 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: ESP Raw Socket: Returned IP packet incorrect
On Jul 12, 2011, at 11:23 AM, Matthew Cini Sarreo wrote: > Thanks for your reply. Where can I find documentation about this? (Or would > it be possible for you to direct me at the proper sources?) At http://fxr.watson.org/fxr/source/netinet/ip_input.c#L464 the length field is converted to host byte order. I have not looked at the Linux sources. I figured it out when writing an SCTP test tool which uses raw socket IO and support Solaris, Linux, FreeBSD and Mac OS X. Best regards Michael > > Thanks & Regards > Matt > > On 11 July 2011 18:01, Michael Tüxen wrote: > On Jul 11, 2011, at 5:26 PM, Matthew Cini Sarreo wrote: > > > Hello all; > > > > I have recently encountered a problem when using raw sockets on FreeBSD 8 > > (8.0-RELEASE) when using ESP raw sockets. > > > > I have created a raw esp socket using: > > socket(AF_INET, SOCK_RAW, 50); > > which works fine. However, when there is a packet on the socket, recvfrom() > > returns a packet where the length bytes in the IP header are incorrect; they > > are swapped (MSB is placed in the LSB and vice-versa) > > > > tcpdump shows the following: > > > > tcpdump: listening on le0, link-type EN10MB (Ethernet), capture size 96 > > bytes > > 15:00:53.993810 IP (tos 0x0, ttl 64, id 0, offset 0, flags [DF], proto ESP > > (50), length 120) > >10.0.251.228 > 10.0.252.231: ESP(spi=0xa0534f17,seq=0x3), length 100 > >0x: 4500 0078 4000 4032 2d88 0a00 fbe4 > >0x0010: 0a00 fce7 a053 4f17 0003 6885 8abd > >0x0020: 5ded 44dc 842f 3081 8fa3 bde4 2265 > >0x0030: 7438 2bf4 049c 664b 7dc4 44ef 1f6f 5e7d > >0x0040: b8c1 482f 8c3b f488 a19a 3d9a d5fe ed9d > >0x0050: b1c2 > > > > > > However, recvfrom() returns the following buffer: > > 4500 6400 0040 4032 2D88 0A00 FBE4 > > 0A00 FCE7 A053 4F17 0003 6885 8ABD > > 5DED 44DC 842F 3081 8FA3 BDE4 2265 > > 7438 2BF4 049C 664B 7DC4 44EF 1F6F 5E7D > > B8C1 482F 8C3B F488 A19A 3D9A D5FE ED9D > > B1C2 > > > > As it is easy to see, the length is not correct (bytes 2 and 3 are 0x6400 > > instead of 0x0064) and it does not correspond to the value returned by > > recvfrom(). > > > > Is this a known issue? Am I missing some options for raw sockets that are > > required for FreeBSD? I have attempted this on a socket to a TUN interface > > (not with an ESP socket) and the buffer had the proper length; it seems to > > only happen with ESP. This code runs fine on multiple Linux distributions > > and on Windows; it was only noticed with FreeBSD. Could it be that there is > > some other ESP application running and interfering (I have not installed > > any; don't know if there are by default and I'm quite new to any of the > > BSDs)? > I think Linux provides the tot_len field in network byte order whereas > FreeBSD provides it in host byte order. At least they expect it that way > when using a send call. > > So you must take care of this in the source code of the application by > using an #ifdef... > > Best regards > Michael > > > > Any help would be much appreciated. > > Matt > > ___ > > 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: sctp cmt problem：using two wireless cards the speed is lower than using one wireless cards
On Sep 14, 2011, at 2:56 PM, jyl_2006 wrote: > Before testing cmt in wlan,we also turn on sysctl states by setting > sysctl net.inet.sctp.cmt_pf=1 > sysctl net.inet.sctp.cmt_use_dac=1 > sysctl net.inet.sctp.cmt_on_off=1 > > My Os is Freebsd8.2, I write a simple tarball to send data , and get data > from wireshark . > The result shows that both two path have data , but the time of two path is > much higher than one path. > > Can anyone point out something we did wrong or steps we missed? Hi, I would suggest to update to the latest version of the code, FreeBSD 9 Beta2. In addition to that, you might want to * enable NR-SACK: sysctl -w net.inet.sctp.nr_sack_on_off=1 * enable send/recv buffer splitting: sysctl -w net.inet.sctp.buffer_splitting=3 This should improve things. I've tested stuff with wired interfaces. Not sure how wireless interference might impact that stuff. Best regards Michael > Thanks in advance. > > > -- > View this message in context: > http://freebsd.1045724.n5.nabble.com/sctp-cmt-problem-using-two-wireless-cards-the-speed-is-lower-than-using-one-wireless-cards-tp4802660p4802660.html > Sent from the freebsd-net mailing list archive at Nabble.com. > ___ > 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: message from sctp getsockopt or sctp_opt_info show error
On Sep 24, 2011, at 3:43 PM, jyl_2006 wrote: > Recently , I use getsockopt or sctp_opt_info to get the information of sctp > association message, both two function return value of 0, and that means > they work well, but the result of testing show some error. > > Here are the result that getting from function getsockopt or sctp_opt_info: > > NO. ASSOC-ID STATE RWND UNACKDATA PENDDATA INSTRMS OUTSTRMS > FRAG-POINT SPINFO-STATE SPINFO-CWDN SPINFO-SRTT SPINFO-RTO SPINFO-MTU > 1 36 ESTABLISHED 573440 010 10 > 1452 ACTIVE 43800 3000 1500 > > other datas have same value with the data show above. > > But the message I get from wireshark ,show the value of RWND is changed > ,when I get a sack. It seems that you are using multiple socket options to get the above values. It doesn't matter whether you use getsockopt() or sctp_opt_info() on FreeBSD. Regarding the RWND: I assume that you print sasoc_peer_rwnd field of the sctp_assocparams structure retrieved via the SCTP_ASSOCINFO socket option. The number provided by the stack is the a_rwnd provided by the peer minus the outstanding data. Doesn't that match you observation? If not, please let me know how to reproduce the problem and which version of FreeBSD you are using. Best regards Michael > > So can anyone point out something we did wrong or steps we missed? > Thanks in advance. > > -- > View this message in context: > http://freebsd.1045724.n5.nabble.com/message-from-sctp-getsockopt-or-sctp-opt-info-show-error-tp4836594p4836594.html > Sent from the freebsd-net mailing list archive at Nabble.com. > ___ > 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: message from sctp getsockopt or sctp_opt_info show error
On Sep 24, 2011, at 3:43 PM, jyl_2006 wrote: > Recently , I use getsockopt or sctp_opt_info to get the information of sctp > association message, both two function return value of 0, and that means > they work well, but the result of testing show some error. > > Here are the result that getting from function getsockopt or sctp_opt_info: > > NO. ASSOC-ID STATE RWND UNACKDATA PENDDATA INSTRMS OUTSTRMS > FRAG-POINT SPINFO-STATE SPINFO-CWDN SPINFO-SRTT SPINFO-RTO SPINFO-MTU > 1 36 ESTABLISHED 573440 010 10 > 1452 ACTIVE 43800 3000 1500 > > other datas have same value with the data show above. > > But the message I get from wireshark ,show the value of RWND is changed > ,when I get a sack. > > So can anyone point out something we did wrong or steps we missed? > Thanks in advance. Just a followup: OK, you use the SCTP_STATUS socket option for the first values. I tested with FreeBSD 9 and get reported the correct values of rwnd. Please provide more information how to reproduce the problem... Best regards Michael > > -- > View this message in context: > http://freebsd.1045724.n5.nabble.com/message-from-sctp-getsockopt-or-sctp-opt-info-show-error-tp4836594p4836594.html > Sent from the freebsd-net mailing list archive at Nabble.com. > ___ > 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: message from sctp getsockopt or sctp_opt_info show error
On Sep 26, 2011, at 4:23 PM, jyl_2006 wrote: > OK ,In Ubuntu, I use getsockopt to get sctp_status with lksctp tarball, the > result show me that only sender get the correct value about cwnd , the > receive's cwnd keep the same value. cwnd does not change when you don't send anything. Also, cwnd is a local variable only available at the sender side. It is not put on the wire. > > Second time, I use Ubuntu as sender and use FreeBSD 9.0 as receiver, and I > does not set any system parameters by using command sysctl. > > Both the receiver and sender set > subscribe.sctp_data_io_event = 1; > subscribe.sctp_association_event = 1; > > The result same with the first time. > > So , does something I did wrong or steps I missed? I'm having a hard time to understand: * What you are observing * What you are expecting * What is the difference between the observed and the expected results. Please be very specific on the three points. Best regards Michael > > -- > View this message in context: > http://freebsd.1045724.n5.nabble.com/message-from-sctp-getsockopt-or-sctp-opt-info-show-error-tp4836594p4841537.html > Sent from the freebsd-net mailing list archive at Nabble.com. > ___ > 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: when enable options SCTP_DEBUG in kernel configure file , where to get the message of debug?
On Sep 30, 2011, at 11:48 AM, jyl wrote: > My Os is FreeBSD 9.0 Beta2. > In kernel configure file, I enable the option of SCTP_DEBUG and rebuild the > kernel. Then I use sctp to send or recv data from another computer ,after > that I check the result from var/log/message or var/log/dmesg , both of the > two files show any message about sctp debug. > > can anyone help me, why it does not work? There is a sysctl variable net.inet.sctp.debug which is a 32-bit bitmask to enable/disable the debug output. To enable all debug output you need to do sudo sysctl -w net.inet.sctp.debug=0x Best regards Michael > > Regards. > > -- > View this message in context: > http://freebsd.1045724.n5.nabble.com/when-enable-options-SCTP-DEBUG-in-kernel-configure-file-where-to-get-the-message-of-debug-tp4856441p4856441.html > Sent from the freebsd-net mailing list archive at Nabble.com. > ___ > 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: SCTP : problems in sending ASCONF chunks
OK, please try two fixes: http://svn.freebsd.org/changeset/base/226868 This fixes a problem which resulted in the ASCONF chunks not being sent. http://svn.freebsd.org/changeset/base/226869 This fixes a problem which resulted in the path confirmation chunks being sent to the wrong destination and therefore not confirming the path. Please let me know if you still have any issues. Best regards Michael On Oct 24, 2011, at 4:20 AM, jyl_2006 wrote: > Hi,Tüxen > > I will provide more detail: > The Topology is: > 1(192.168.1.20) > computer A ---1 computer B(192.168.1.80) > 2(192.168.1.50) > means computer has two wireless cards , I name them with A_1 and A_2, > computer B has one wireless cards, and its name is B_1. > > Now, A_1 init a association with B_1. Here, I provide message getting from > wireshark , > INIT： > Internet Protocol, Src: 192.168.1.20 (192.168.1.20), Dst: 192.168.1.80 > (192.168.1.80) > Supported Extensions parameter (Supported types: ASCONF, ASCONF_ACK, > FORWARD_TSN, PKTDROP, STREAM_RESET, AUTH) > INIT ACK: > Internet Protocol, Src: 192.168.1.80 (192.168.1.80), Dst: 192.168.1.20 > (192.168.1.20) > Supported Extensions parameter (Supported types: ASCONF, ASCONF_ACK, > FORWARD_TSN, PKTDROP, STREAM_RESET, AUTH) > > Debug message: > SCTP_SACK process cum_ack:45452434 num_seg:0 a_rwnd:1864135 > Check for chunk output prw:1864135 tqe:1 tf=0 > Send called addr:0xc591c980 send length 2 > Calling ipv4 output routine from low level src addr:c0a80114 > Destination is c0a80150 > RTP route is 0xc5caaaf8 through > IP output returns 0 > m-c-o put out 1 > Ok, we have put out 1 chunks > USR Send complete qo:0 prw:1863859 unsent:18 tf:18 cooq:1 toqs:18 err:0 > Ok laddr->ifa:0xc5baab00 is possible, asconf_queue_mgmt: inserted asconf > ADD_IP_ADDRESS: IPv4 address: 192.168.1.50:0 > m-c-o put out 0 > Ok, we have put out 0 chunks > sctp_input() length:28 iphlen:20 > sctp_input(): Packet of length 48 received on wlan0 with csum_flags 0x0. > Ok, Common input processing called, m:0xc72dab00 iphlen:20 offset:32 > length:48 stcb:0xcc2335dc > stcb:0xcc2335dc state:8 > sctp_process_control: iphlen=20, offset=32, length=48 stcb:0xcc2335dc > sctp_process_control: processing a chunk type=3, len=16 > > Actually,I also test following Topology : > 1(192.168.1.20) > --1(192.168.1.80) > computer A --- computer B > 2(192.168.2.20) > --2(192.168.2.80) > means computer has two wireless cards , I name them with A_1 and A_2, > computer B has two wireless cards, and its name is B_1 and B_2. > > The result from wireshark and debug message have same results. > > > -- > View this message in context: > http://freebsd.1045724.n5.nabble.com/SCTP-problems-in-sending-ASCONF-chunks-tp4929128p4931035.html > Sent from the freebsd-net mailing list archive at Nabble.com. > ___ > 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: Problem with sbdrop panic
On Nov 10, 2011, at 8:45 AM, Chen, Kang (NSN - CN/Hangzhou) wrote: > Hi, freebsd expert > > I'm using freebsd 6.2 version and I encounter a sbdrop panic problem. Are you really using 6.2? This version is very old? Can you upgrade to one of the 9.0 release candidates and see if the problem persists? > I establish several sctp association between client and server, after I > restart the client, then the server also restart caused by sbdrop panic. > Hopefully can get your help with this problem. What you you mean by "restart the client"? Best regards Michael > > > Best Regards, > Chen Kang > 2011-11-10 > ___ > 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: possible array out of bounds access in sys/netinet/sctp_output.c
On Nov 27, 2011, at 5:24 PM, Jilles Tjoelker wrote: > On Sun, Nov 27, 2011 at 03:45:36PM +, Alexander Best wrote: >> i've been playing with clang tot and noticed the following error: > >> /usr/local/bin/clang -c -O3 -pipe -fno-inline-functions -fno-strict-aliasing >> -march=core2 -std=c99 -g -fdiagnostics-show-option -fformat-extensions -Wall >> -Wcast-qual -Winline -Wmissing-include-dirs -Wmissing-prototypes >> -Wnested-externs -Wpointer-arith -Wredundant-decls -Wstrict-prototypes >> -Wundef -Wno-pointer-sign -nostdinc -I. -I/usr/git-freebsd-head/sys >> -I/usr/git-freebsd-head/sys/contrib/altq -D_KERNEL >> -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-omit-frame-pointer >> -mno-aes -mno-avx -mcmodel=kernel -mno-red-zone -mno-mmx -msoft-float >> -fno-asynchronous-unwind-tables -ffreestanding >> -Wno-error=tautological-compare -Wno-error=shift-count-negative >> -Wno-error=shift-count-overflow -Wno-error=shift-overflow >> -Wno-error=conversion -Wno-error=empty-body -Wno-error=gnu-designator >> -Wno-error=format -Wno-error=format-invalid-specifier >> -Wno-error=format-extra-args -Werror >> /usr/git-freebsd-head/sys/netinet/sctp_output.c >> clang: warning: argument unused during compilation: '-fformat-extensions' >> /usr/git-freebsd-head/sys/netinet/sctp_output.c:4685:2: error: array index 1 >> is past the end of the array (which contains 1 element) >> [-Werror,-Warray-bounds] >>sup_addr->addr_type[1] = htons(SCTP_IPV6_ADDRESS); >>^ ~ >> /usr/git-freebsd-head/sys/netinet/sctp_header.h:84:2: note: array >> 'addr_type' declared here >>uint16_t addr_type[SCTP_ARRAY_MIN_LEN]; /* array of supported address >>^ >> 1 error generated. >> *** Error code 1 >> >> Stop in /usr/obj/usr/git-freebsd-head/sys/GENERIC. >> *** Error code 1 >> >> Stop in /usr/git-freebsd-head. >> *** Error code 1 >> >> Stop in /usr/git-freebsd-head. > >> this is from a GENERIC kernel build (so INET + INET6) for amd64. is this a >> false positive, or is length(sup_addr->addr_type) really == 1, thus making >> sup_addr->addr_type[1] an illegal access? > > This is the fairly common construct of a variable-length array at the > end of a struct. With C89, this was not allowed but defining one element > and allocating more elements worked in most implementations. C99 > recognized this need and created a way to do it, which looks like > uint16_t addr_type[];. This adds any necessary padding and allows access > to however many elements have been allocated. Also, if it is not at the > end of a struct it is an error. > > Using this new construct requires code changes because some code such as > fairly close to the error message relies on the size of the one element > already in the struct. Hi Jilles, you are completely right. It is a false positive. the reason why we don't use addr_type[] is that the same code is used on different plattforms and (at least at one point of time), using addr_type[] didn't work there. However, reconsidering the code right now, I guess one could change to code in a way to avoid the warning. I'll put that on my ToDo list. But it is only to avoid the warning, there is no real problem as said earlier. Best regards Michael > > -- > Jilles Tjoelker > ___ > 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: possible array out of bounds access in sys/netinet/sctp_output.c
On Nov 27, 2011, at 5:56 PM, Davide Italiano wrote: > On Sun, Nov 27, 2011 at 5:24 PM, Jilles Tjoelker wrote: >> On Sun, Nov 27, 2011 at 03:45:36PM +, Alexander Best wrote: >>> i've been playing with clang tot and noticed the following error: >> >>> /usr/local/bin/clang -c -O3 -pipe -fno-inline-functions >>> -fno-strict-aliasing -march=core2 -std=c99 -g -fdiagnostics-show-option >>> -fformat-extensions -Wall -Wcast-qual -Winline -Wmissing-include-dirs >>> -Wmissing-prototypes -Wnested-externs -Wpointer-arith -Wredundant-decls >>> -Wstrict-prototypes -Wundef -Wno-pointer-sign -nostdinc -I. >>> -I/usr/git-freebsd-head/sys -I/usr/git-freebsd-head/sys/contrib/altq >>> -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h >>> -fno-omit-frame-pointer -mno-aes -mno-avx -mcmodel=kernel -mno-red-zone >>> -mno-mmx -msoft-float -fno-asynchronous-unwind-tables -ffreestanding >>> -Wno-error=tautological-compare -Wno-error=shift-count-negative >>> -Wno-error=shift-count-overflow -Wno-error=shift-overflow >>> -Wno-error=conversion -Wno-error=empty-body -Wno-error=gnu-designator >>> -Wno-error=format -Wno-error=format-invalid-specifier >>> -Wno-error=format-extra-args -Werror >>> /usr/git-freebsd-head/sys/netinet/sctp_output.c >>> clang: warning: argument unused during compilation: '-fformat-extensions' >>> /usr/git-freebsd-head/sys/netinet/sctp_output.c:4685:2: error: array index >>> 1 is past the end of the array (which contains 1 element) >>> [-Werror,-Warray-bounds] >>> sup_addr->addr_type[1] = htons(SCTP_IPV6_ADDRESS); >>> ^ ~ >>> /usr/git-freebsd-head/sys/netinet/sctp_header.h:84:2: note: array >>> 'addr_type' declared here >>> uint16_t addr_type[SCTP_ARRAY_MIN_LEN]; /* array of supported >>> address >>> ^ >>> 1 error generated. >>> *** Error code 1 >>> >>> Stop in /usr/obj/usr/git-freebsd-head/sys/GENERIC. >>> *** Error code 1 >>> >>> Stop in /usr/git-freebsd-head. >>> *** Error code 1 >>> >>> Stop in /usr/git-freebsd-head. >> >>> this is from a GENERIC kernel build (so INET + INET6) for amd64. is this a >>> false positive, or is length(sup_addr->addr_type) really == 1, thus making >>> sup_addr->addr_type[1] an illegal access? >> >> This is the fairly common construct of a variable-length array at the >> end of a struct. With C89, this was not allowed but defining one element >> and allocating more elements worked in most implementations. C99 >> recognized this need and created a way to do it, which looks like >> uint16_t addr_type[];. This adds any necessary padding and allows access >> to however many elements have been allocated. Also, if it is not at the >> end of a struct it is an error. >> >> Using this new construct requires code changes because some code such as >> fairly close to the error message relies on the size of the one element >> already in the struct. >> >> -- >> Jilles Tjoelker >> ___ >> freebsd-curr...@freebsd.org mailing list >> http://lists.freebsd.org/mailman/listinfo/freebsd-current >> To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org" >> > > > I looked at sctp_send_initiate() and it seems that independently from > the number of types supported (IPV6/IPV4 or both) two elements are > allocated in the array sup_addr->addr_type[0] . In case only a type is > supported one of the elements is simply padding. > (http://fxr.watson.org/fxr/source/netinet/sctp_output.c#L4670) . > > So, this should fix the issue, but maybe I'm wrong so feel free to correct me. > > http://davit.altervista.org/sctp_header_types.diff > > I defined a new macro mainly because SCTP_ARRAY_MIN_LEN is used in > another place, i.e. in the field name of struct sctp_host_name_param, > defined in sctp_header.h). Thanks to arundel@ for testing. The problem with your fix is that the size of the structure is used in the code and there are also changes required. When looking at the code to avoid the warning I realized that the supported address types parameters will have a wrong length if the kernel is build with either INET or INET6, but not both. I've committed a fix in http://svn.freebsd.org/changeset/base/228031 Best regards Michael > > Regards > > Davide > ___ > 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: the return value of sctp_connectx do not match any error
On Dec 2, 2011, at 3:07 PM, jyl_2006 wrote: > Hi, > I use FreeBSD 9.0 Beta2. > When I use sctp_connectx to init a new association , the return value of > this function is strange. > The return value is not any of following:1.EINVAL, 2.E2BIG, 3.EBADOF, > 4.ENOTSOCK. Hi, the return value should be 0 (for success) or -1 (in case of an error). Only if -1 is returned, errno is set to an appropriate value. Can you provide a small test program demonstrating the issue? Best regards Michael > > I use perror() function to see detail, it shows that " Resource temporarily > unavailable". > > Thanks. > > -- > View this message in context: > http://freebsd.1045724.n5.nabble.com/the-return-value-of-sctp-connectx-do-not-match-any-error-tp5041952p5041952.html > Sent from the freebsd-net mailing list archive at Nabble.com. > ___ > 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: the return value of sctp_connectx do not match any error
On Dec 3, 2011, at 5:54 AM, jyl_2006 wrote:
> First, I use the return value of sctp_connectx, and I do not use errno, so
> the return value does not match the errors gived in manual. Now,I know it is
> my mistake.
>
> However, I write a simple program to test sctp_connectx, it still show
> error.The errno is "EINVAL", I am sure that the paraments are set properly.
>
> One more thing, I also test these programs in other platform, the result is
> OK, but under FreeBSD, it does not work.
In BSD you need to set the sin_len field of the sockaddr_in structure.
So if you add
server_ipaddress . sin_len = sizeof(struct sockaddr_in);
the client works (at least it does for me).
You should do the same for the server...
Please let me know if your problem persists.
Best regards
Michael
>
> /*Here are programs.*/
>
> #include
> #include
> #include
>
> #include
> #include
> #include
> #include
> #define PORT 63000
> #define MTU 1500
>
> int main()
> {
> int _listenfd, _sctp_socket, _connfd;
> struct sockaddr_in servaddr;
> int ret, msg_flag;
> char message[MTU];
> struct sctp_sndrcvinfo sndrcvinfo;
>
> _sctp_socket = socket( AF_INET , SOCK_SEQPACKET , IPPROTO_SCTP );
>
> bzero( (void *)&servaddr, sizeof(servaddr) );
> servaddr.sin_family = AF_INET;
> servaddr.sin_addr.s_addr = htonl( INADDR_ANY );
> servaddr.sin_port = htons(PORT);
>
> ret = bind(_sctp_socket, (struct sockaddr *)&servaddr,
> sizeof(servaddr));
> if( ret )
> {
> printf("Server bind error" );
> }
>
> _listenfd= listen(_sctp_socket, 10);
> if(0 != _listenfd)
> {
> printf("Server listen error" );
> }
>
> ret = sctp_recvmsg(_sctp_socket, (void *)message , MTU, NULL, 0 ,
> &sndrcvinfo , &msg_flag);
> if(ret >= 0)
> {
> printf("Receive message:%s", message);
> }
> }
>
>
> #include
> #include
> #include
>
> #include
> #include
> #include
> #include
> #define PORT 63000
>
> int main()
> {
> int _sctp_socket, _sctp_associd, ret;
> _sctp_socket = socket( AF_INET , SOCK_SEQPACKET , IPPROTO_SCTP );
>
> struct sockaddr_in server_ipaddress;
> server_ipaddress . sin_family = AF_INET;
> server_ipaddress . sin_port = htons(PORT);
> server_ipaddress . sin_addr.s_addr = inet_addr("127.0.0.1");
>
> ret = sctp_connectx(_sctp_socket , (struct sockaddr*) &server_ipaddress
> ,
> 1, &_sctp_associd);
>if( ret < 0)
>{
> printf("sctp_connectx error");
>}
> }
>
>
>
>
>
>
> --
> View this message in context:
> http://freebsd.1045724.n5.nabble.com/the-return-value-of-sctp-connectx-do-not-match-any-error-tp5041952p5043901.html
> Sent from the freebsd-net mailing list archive at Nabble.com.
> ___
> 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: the return value of sctp_connectx do not match any error
On Dec 3, 2011, at 2:34 PM, jyl_2006 wrote: > Hi, Michael > The problem about sctp_connectx is solved.Thank you very much. > > But I encounter another problem, it's about sctp_getladdrs().Every time I > call this function, the return value is "ENOMEM". Even I reboot the > computer, this problem still exists. The return value is the number of addresses, not an error code. So if it returns ENOMEM, it means that your endpoint has 12 addresses. Or does it return -1 and errno is set to ENOMEM? Best regards Michael > > My function is: > struct sockaddr*show_ip_address = NULL; > sctp_getladdrs(_sctp_socket, _sctp_associd, &show_ip_address); > > > > -- > View this message in context: > http://freebsd.1045724.n5.nabble.com/the-return-value-of-sctp-connectx-do-not-match-any-error-tp5041952p5044536.html > Sent from the freebsd-net mailing list archive at Nabble.com. > ___ > 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: the return value of sctp_connectx do not match any error
On Dec 4, 2011, at 3:42 AM, jyl_2006 wrote:
> Sorry.The return value is -1, that means sctp_getladdrs() and
> sctp_getpaddrs() encounter an error. And the errno is set to ENOMEM.
Can you provide a test program showing this?
I changed your client and this works on a FreeBSD head system. Does it fail on
your?
Best regards
Michael
#include
#include
#include
#include
#include
#include
#include
#define PORT 63000
int main()
{
int _sctp_socket, ret;
sctp_assoc_t _sctp_associd;
struct sockaddr *show_ip_address = NULL;
_sctp_socket = socket( AF_INET , SOCK_SEQPACKET , IPPROTO_SCTP );
struct sockaddr_in server_ipaddress;
server_ipaddress . sin_family = AF_INET;
server_ipaddress . sin_port = htons(PORT);
server_ipaddress . sin_len = sizeof(struct sockaddr_in);
server_ipaddress . sin_addr.s_addr = inet_addr("127.0.0.1");
ret = sctp_connectx(_sctp_socket , (struct sockaddr*) &server_ipaddress
, 1, &_sctp_associd);
if( ret < 0)
{
printf("sctp_connectx error");
}
ret = sctp_getladdrs(_sctp_socket, _sctp_associd, &show_ip_address);
printf("sctp_getladdrs() returned %d.\n", ret);
if (ret > 0)
{
sctp_freeladdrs(show_ip_address);
}
}
>
> --
> View this message in context:
> http://freebsd.1045724.n5.nabble.com/the-return-value-of-sctp-connectx-do-not-match-any-error-tp5041952p5045598.html
> Sent from the freebsd-net mailing list archive at Nabble.com.
> ___
> 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: the return value of sctp_connectx do not match any error
On Dec 4, 2011, at 1:01 PM, jyl_2006 wrote: > I change the code , and the return value of sctp_getladdrs() is still -1, and > the errno is "ENOMEM". What does "change the code" mean? Are you saying that the program I sent does not work? If my program does work, can you send me your program which doesn't? Best regards Michael > > My operating system is FreeBSD 9.0 Beta2. > > Thanks. > > -- > View this message in context: > http://freebsd.1045724.n5.nabble.com/the-return-value-of-sctp-connectx-do-not-match-any-error-tp5041952p5046113.html > Sent from the freebsd-net mailing list archive at Nabble.com. > ___ > 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: the return value of sctp_connectx do not match any error
On Dec 4, 2011, at 1:30 PM, jyl_2006 wrote: > Yes, I mean the program you send does not work. OK, let me test... Do you have IPv4 addresses configured on your system? Best regards Michael > > -- > View this message in context: > http://freebsd.1045724.n5.nabble.com/the-return-value-of-sctp-connectx-do-not-match-any-error-tp5041952p5046165.html > Sent from the freebsd-net mailing list archive at Nabble.com. > ___ > 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: the return value of sctp_connectx do not match any error
On Dec 4, 2011, at 2:14 PM, jyl_2006 wrote: > Yes, besides "127.0.0.1" , I also test between two computer, each one have ip > address of wlan.The question still remains. I'm downloading a RC2 image and will use the programs to try to reproduce the problem. Are you running an amd64 or an i386 kernel (I did testing with amd64...)? best regards Michael > > -- > View this message in context: > http://freebsd.1045724.n5.nabble.com/the-return-value-of-sctp-connectx-do-not-match-any-error-tp5041952p5046216.html > Sent from the freebsd-net mailing list archive at Nabble.com. > ___ > 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: the return value of sctp_connectx do not match any error
On Dec 4, 2011, at 2:14 PM, jyl_2006 wrote:
> Yes, besides "127.0.0.1" , I also test between two computer, each one have ip
> address of wlan.The question still remains.
OK, I have tested RC2 i386 and it works. I don't have a Beta 2 system...
I have no idea what the problem might be... What does the following program
report?
Best regards
Michael
#include
#include
#include
#include
#include
#include
#include
#include
#define PORT 63000
int main()
{
int _sctp_socket, ret;
sctp_assoc_t _sctp_associd;
struct sockaddr *show_ip_address = NULL;
int size_of_addresses;
socklen_t siz;
struct sctp_getaddresses *addrs;
_sctp_socket = socket( AF_INET , SOCK_SEQPACKET , IPPROTO_SCTP );
struct sockaddr_in server_ipaddress;
server_ipaddress . sin_family = AF_INET;
server_ipaddress . sin_port = htons(PORT);
server_ipaddress . sin_len = sizeof(struct sockaddr_in);
server_ipaddress . sin_addr.s_addr = inet_addr("127.0.0.1");
ret = sctp_connectx(_sctp_socket , (struct sockaddr*) &server_ipaddress
, 1, &_sctp_associd);
if( ret < 0)
{
printf("sctp_connectx error");
}
size_of_addresses = 0;
siz = sizeof(int);
if (getsockopt(_sctp_socket, IPPROTO_SCTP, SCTP_GET_LOCAL_ADDR_SIZE,
&size_of_addresses, &siz) != 0) {
perror("SCTP_GET_LOCAL_ADDR_SIZE");
return (-1);
}
printf("size_of_addresses = %d.\n", size_of_addresses);
siz = size_of_addresses + sizeof(struct sockaddr_storage);
siz += sizeof(struct sctp_getaddresses);
addrs = calloc(1, siz);
addrs->sget_assoc_id = _sctp_associd;
if (getsockopt(_sctp_socket, IPPROTO_SCTP, SCTP_GET_LOCAL_ADDRESSES,
addrs, &siz) != 0) {
perror("SCTP_GET_LOCAL_ADDRESSES");
return (-1);
}
printf("siz = %u.\n", siz);
free(addrs);
return (0);
}
>
> --
> View this message in context:
> http://freebsd.1045724.n5.nabble.com/the-return-value-of-sctp-connectx-do-not-match-any-error-tp5041952p5046216.html
> Sent from the freebsd-net mailing list archive at Nabble.com.
> ___
> 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: the return value of sctp_connectx do not match any error
On Dec 5, 2011, at 4:10 AM, jyl_2006 wrote:
> This time, the program you provide work perfectly.
> But when I use another program to test, the result
> is"SCTP_GET_LOCAL_ADDRESS:no such file or directory".
This means that you are using a one-to-many style socket (SOCK_SEQPACKET)
and you provide an association identifier which does not belong
to any association (anymore).
>
> /*My own program have the same set with the program you provide, that means
> the ip address is the same and both programs have same "Server to be
> connected" .
> The "siz" refered in the following code is different with the value I get
> from my another program*/
>
> if (getsockopt(_sctp_socket, IPPROTO_SCTP, SCTP_GET_LOCAL_ADDRESSES, addrs,
> &siz) != 0) {
>perror("SCTP_GET_LOCAL_ADDRESSES");
>return (-1);
> }
>printf("siz = %u.\n", siz);
>
> As far as I know, then getsockopt is fail, the return value is -1, and the
> errno is set as one of following values 1.EBADF, 2.ENOTSOCK, 3.ENOPROTOOPT
> 4.EFAULT, 5.EINVAL . In my own program I use return_value =
This is from the man page. In case of SCTP socket it seems to miss some
error codes...
> getsockopt(_sctp_socket, IPPROTO_SCTP, SCTP_GET_LOCAL_ADDRESSES, addrs,
> &siz), the value of return_value is -1, so it means an error happened and
> errno will be set. A strange thing happens, the errno is not the values
> refered above.
So which one is it? The man page seems to need some update.
Best regards
Michael
>
> Thanks.
>
> --
> View this message in context:
> http://freebsd.1045724.n5.nabble.com/the-return-value-of-sctp-connectx-do-not-match-any-error-tp5041952p5047743.html
> Sent from the freebsd-net mailing list archive at Nabble.com.
> ___
> 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: the return value of sctp_connectx do not match any error
On Dec 5, 2011, at 2:59 PM, jyl_2006 wrote: > I download freebsd-rc2(Character-based) and use the new Operating system to > run the code you provide(sctp_client.c and give name of ComputerA to the > computer it uses).In another computer(named ComputerB) I run > freebsd-beta2(Graphical interface), I use the code(sctp_server.c) and I use > wireshark to see what happen. > > I do not run sctp_server(means no server to wait for accept) in ComputerA , > the program of sctp_client in ComputerB use sctp_connectx to init the > association, the return value of sctp_connectx is 0 , that means the > association is set up, but I do not run any server in computerA and the > wireshark also see the init of association is unsuccessful. No. If sctp_connectx() it means that initiating the setup was successful, basically the sending on the INIT chunk. It is a non-blocking operation. So I guess this is what happens: 1. You call sctp_connectx(). 2. An INIT is sent. 3. sctp_connectx() returns with 0. The associd is valid. 4. An ABORT comes back. 5. Now the association is closed. If you want a blocking setup, use a one-to-one style socket and a connect() call. If you want to figure out whether the association setup is successful or not, you have to subscribe to the corresponding events. You will either get a notification indicating that the setup is successful or not. I don't think this behavior has changed between RC2 and B2. Best regards Michael > > I am really confused about this problem. > > Thanks. > > -- > View this message in context: > http://freebsd.1045724.n5.nabble.com/the-return-value-of-sctp-connectx-do-not-match-any-error-tp5041952p5048925.html > Sent from the freebsd-net mailing list archive at Nabble.com. > ___ > 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: Removal of deprecated implied connect for TCP
On Aug 31, 2010, at 12:04 PM, Robert Watson wrote: > > On Sun, 29 Aug 2010, Andre Oppermann wrote: > >> When T/TCP RFC1644 support was introduced in r6283 by wollman 15 years ago >> the semantics of sendto(2) with regard to TCP sockets were changed. >> >> It became possible directly do a sendto(2) call with the target address in >> the *to argument instead of doing a connect(2) first and subsequent write(2) >> or send(2) calls as the standard TCP API specifies. Optionally MSG_EOR >> could be specified to close the connection again right again after the data >> has been sent out. >> >> This is totally non-portable and no other OS (Linux, NetBSD, OpenBSD, >> Solaris, HP-UX) ever supported this functionality for TCP sockets. FreeBSD >> was the only OS to ever ship this. >> >> T/TCP was ill-defined and had major security issues and never gained any >> support. It has been defunct in FreeBSD and most code has been removed about >> 6 years ago. The sendto(2) extended functionality is one of the last parts >> that persisted and remained around living a zombie life. >> >> I want to remove it now because it is totally non-portable, has no known >> users and complicates the TCP send path. The patch is attached. >> >> If you have any objections speak up now. > > I'm not entirely comfortable with this change, and would like a chance to > cogitate on it a bit more. While I'm not aware of any applications depending > on the semantic for TCP, I know that we do use it for UNIX domain sockets. > Since it's a documented API, if we are going to remove it, then we need to go > through a deprecation process, not least by marking it as a deprecated API in > 8.x before having it vanish in 9.0. sendto() is also used for SCTP SOCK_STREAMS and SOCK_SEQPACKET sockets... Best regards Michael > > (I won't be sorry to see the complexity go, but I'm not sure I have all the > implications in mind as yet...) > > Robert > ___ > 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: [SCTP] last_sequence_delivered in sctp_process_a_data_chunk question
On Dec 15, 2010, at 8:46 AM, 罗钰 wrote:
> Hi, all experts:I find a suspect point in function of
> sctp_process_a_data_chunk in all FreeBSD branches.for example:Line 1900 of
> sctp_indata: (asoc->strmin[strmno].last_sequence_delivered + 1) ==
> strmseqThis is a logical judgement sentence.last_sequence_delivered is
> unsigned short type, strmseq is also.there is a problem: if
> last_sequence_delivered equal 0x, and the result of
> last_sequence_delivered + 1 must be 0x1, rather than 0x, and if
> strmseq is also be 0x0, then this judgement will give you wrong value.
> so i think put a (uint16_t) before this sentence will be more secure. so how
> do you think?like this:
> (uint16_t)(asoc->strmin[strmno].last_sequence_delivered + 1) == strmseqThanks
> and i hope your response.
In head and FreeBSD 8.0 and 8.1 sctp_structs.h contains:
struct sctp_stream_in {
struct sctp_readhead inqueue;
uint16_t stream_no;
uint16_t last_sequence_delivered; /* used for re-order */
uint8_t delivery_started;
};
Furthermore sctp_process_a_data_chunk() contains:
uint16_t strmno, strmseq;
So I do not think the problem "is in all branches". Can you be more specific,
which version your are talking about?
Best regards
Michael
>
>
>
> ___
> 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: [SCTP] transport address unconfirmed instead of inactive
On Jan 17, 2011, at 8:11 AM, Schoch Christian wrote: > I did some test with multihoming and failover. My problem is that if one > transport failes it never comes back to active (no heartbeats are sent any > more). > > My setup: > > FreeBSD 8.1 Linux 2.6.36 > 172.16.1.4 - 172.16.1.3 > 172.17.1.4 - 172.17.1.3 > > Packets from 16.1.4 to 17.1.3 and 17.1.4 to 16.1.3 are dropped. > > The transfer starts with 172.16.1.4 to 16.1.3 which is working as expected. Which side is the client, which one is the server? Which side is sending user data? > If the transfer on this transport failes, it is switching to 17.1.4 & 17.1.3 > as expected. How do you fail the connection? Disconnecting the cable? Configuring dummynet? > 172.16.1.4 gets SCTP_UNCONFIRMED, 172.16.1.3 gets SCTP_INACTIVE So you mean on the FreeBSD machine you get a SCTP_UNCONFIRMED? For which address? 172.16.1.3? > Now, if the first connection is available again, the first transport address > of FreeBSD stays at unconfirmed with no HB sent to 16.1.3 > Linux sends HB from 16.1.3 to 16.1.4 with ACK coming back from 17.1.4 to > 16.1.3 (which is dropped). > > So why are HBs sent from new primary instead of received address ? As > specified in RFC it should sent back from address, it receives the HB packet. Correct. Somethings seems strange. Please answer the above and I will try to reproduce the problem. Thanks for the report. Best regards Michael > > Regards, > Christian > > > > This message was sent using IMP, the Internet Messaging Program. > > ___ > 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: [SCTP] transport address unconfirmed instead of inactive
On Jan 19, 2011, at 11:02 PM, Schoch Christian wrote: > Dear Michael, > > as I could figure out, the problem with UNCONFIRMED is solved. My test tools > is based on lksctp-tools and written for linux testing. Now the problem here > is that there is a inconsistency between linux and FreeBSD of the return > value of spinfo_state. Perhaps these return values could be standardized in > the sctp socket-api. Leaving a note on the linux dev mailing list on this > topic. Hi Christian, the actual values are not standardized, only the names of the constants. If you use the names and recompile the code when moving from Linux to FreeBSD, it should work. > > The other problem may depend on the fact, that i did the test with vmware and > a remote machine using only one network interface with 2 different Addresses > assigned. Furthermore, both addresses had a netmask of 255.255.0.0 so both > addresses were located in the same subnet. Did the same test with 2 Vmware > machines and other addresses which was successful. Yes, that mask may result in problems. Thanks for reporting. Best regards Michael > > Regards, > Christian > >> On Jan 17, 2011, at 8:11 AM, Schoch Christian wrote: >> >>> I did some test with multihoming and failover. My problem is that if one >>> transport failes it never comes back to active (no heartbeats are sent any >>> more). >>> >>> My setup: >>> >>> FreeBSD 8.1 Linux 2.6.36 >>> 172.16.1.4 - 172.16.1.3 >>> 172.17.1.4 - 172.17.1.3 >>> >>> Packets from 16.1.4 to 17.1.3 and 17.1.4 to 16.1.3 are dropped. >>> >>> The transfer starts with 172.16.1.4 to 16.1.3 which is working as expected. >> Which side is the client, which one is the server? Which side is sending user >> data? >>> If the transfer on this transport failes, it is switching to 17.1.4 & >>> 17.1.3 as expected. >> How do you fail the connection? Disconnecting the cable? Configuring >> dummynet? >>> 172.16.1.4 gets SCTP_UNCONFIRMED, 172.16.1.3 gets SCTP_INACTIVE >> So you mean on the FreeBSD machine you get a SCTP_UNCONFIRMED? For which >> address? 172.16.1.3? >>> Now, if the first connection is available again, the first transport >>> address of FreeBSD stays at unconfirmed with no HB sent to 16.1.3 >>> Linux sends HB from 16.1.3 to 16.1.4 with ACK coming back from 17.1.4 to >>> 16.1.3 (which is dropped). >>> >>> So why are HBs sent from new primary instead of received address ? As >>> specified in RFC it should sent back from address, it receives the HB >>> packet. >> Correct. Somethings seems strange. Please answer the above and I will try to >> reproduce >> the problem. >> >> Thanks for the report. >> Best regards >> Michael >>> >>> Regards, >>> Christian >>> >>> >>> >>> This message was sent using IMP, the Internet Messaging Program. >>> >>> ___ >>> 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: igb driver RX (was TX) hangs when out of mbuf clusters
On Feb 8, 2011, at 10:10 AM, Lev Serebryakov wrote: > Hello, Karim. > You wrote 8 февраля 2011 г., 6:29:53: > >> Precisely, the exact same behavior happens (RX hang) if options >> DEVICE_POLLING is _not_ used in the kernel configuration file. I tried with >> POLLING since someone mentioned that it helped in a case mentioned earlier >> today. Unfortunately for igb with or without polling yields the same rx ring >> filing problem. > In my case (em(4), not igb(4) but symptoms are VERY similar) POLLING > (both as kernel option AND "ifconfig em0 polling") options leads to > resets (which drops all connections!) AFTER such kernel messages: > > em0: Watchdog timeout -- resetting > em0: Queue(0) tdh = 1302, hw tdt = 1265 > em0: TX(0) desc avail = 31,Next TX to Clean = 1296 Can you apply the attached patch and report what the output for rx_nxt_refresh and rx_nxt_check is? Best regards Michael patch Description: Binary data > > -- > // Black Lion AKA Lev Serebryakov > > ___ > 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: igb driver RX (was TX) hangs when out of mbuf clusters
On Feb 8, 2011, at 4:29 AM, Karim Fodil-Lemelin wrote: > 2011/2/7 Pyun YongHyeon > >> On Mon, Feb 07, 2011 at 09:21:45PM -0500, Karim Fodil-Lemelin wrote: >>> 2011/2/7 Pyun YongHyeon >>> On Mon, Feb 07, 2011 at 05:33:47PM -0500, Karim Fodil-Lemelin wrote: > Subject: Re: igb driver tx hangs when out of mbuf clusters > >> To: Lev Serebryakov >> Cc: freebsd-net@freebsd.org >> >> >> 2011/2/7 Lev Serebryakov >> >> Hello, Karim. >>> You wrote 7 февраля 2011 г., 19:58:04: >>> >>> The issue is with the igb driver from 7.4 RC3 r218406. If the >> driver >>> runs out of mbuf clusters it simply stops receiving even after the clusters >>> have been freed. >>> It looks like my problems with em0 (see thread "em0 hangs >> without >>> any messages like "Watchdog timeout", only down/up reset it.")... >>> Codebase for em and igb is somewhat common... >>> >>> -- >>> // Black Lion AKA Lev Serebryakov >>> >>> I agree. >> >> Do you get missed packets in mac_stats (sysctl dev.em | grep >> missed)? >> >> I might not have mentioned but I can also 'fix' the problem by >> doing >> ifconfig igb0 down/up. >> >> I will try using POLLING to 'automatize' the reset as you mentioned >> in your >> thread. >> >> Karim. >> >> > Follow up on tests with POLLING: The problem is still occurring >> although it > takes more time ... Outputs of sysctl dev.igb0 and netstat -m will follow: > > 9219/99426/108645 mbufs in use (current/cache/total) > 9217/90783/10/10 mbuf clusters in use >> (current/cache/total/max) Do you see network processes are stuck in keglim state? If you see that I think that's not trivial to solve. You wouldn't even kill that process if it is under keglim state unless some more mbuf clusters are freed from other places. >>> >>> No keglim state, here is a snapshot of top -SH while the problem is >>> happening: >>> >>> 12 root 171 ki31 0K 8K CPU5 5 19:27 100.00% idle: >>> cpu5 >>> 10 root 171 ki31 0K 8K CPU7 7 19:26 100.00% idle: >>> cpu7 >>> 14 root 171 ki31 0K 8K CPU3 3 19:25 100.00% idle: >>> cpu3 >>> 11 root 171 ki31 0K 8K CPU6 6 19:25 100.00% idle: >>> cpu6 >>> 13 root 171 ki31 0K 8K CPU4 4 19:24 100.00% idle: >>> cpu4 >>> 15 root 171 ki31 0K 8K CPU2 2 19:22 100.00% idle: >>> cpu2 >>> 16 root 171 ki31 0K 8K CPU1 1 19:18 100.00% idle: >>> cpu1 >>> 17 root 171 ki31 0K 8K RUN0 19:12 100.00% idle: >>> cpu0 >>> 18 root -32- 0K 8K WAIT 6 0:04 0.10% swi4: >>> clock s >>> 20 root -44- 0K 8K WAIT 4 0:08 0.00% swi1: >> net >>> 29 root -68- 0K 8K - 0 0:02 0.00% igb0 >> que >>> 35 root -68- 0K 8K - 2 0:02 0.00% em1 >> taskq >>> 28 root -68- 0K 8K WAIT 5 0:01 0.00% irq256: >>> igb0 >>> >>> keep in mind that num_queues has been forced to 1. >>> >>> I think both igb(4) and em(4) pass received frame to upper stack before allocating new RX buffer. If driver fails to allocate new RX buffer driver will try to refill RX buffers in next run. Under extreme resource shortage case, this situation can produce no more RX buffers in RX descriptor ring and this will take the box out of network. Other drivers avoid that situation by allocating new RX buffer before passing received frame to upper stack. If RX buffer allocation fails driver will just reuse old RX buffer without passing received frame to upper stack. That does not completely solve the keglim issue though. I think you should have enough mbuf cluters to avoid keglim. However the output above indicates you have enough free mbuf clusters. So I guess igb(4) encountered zero available RX buffer situation in past but failed to refill the RX buffer again. I guess driver may be able to periodically check available RX buffers. Jack may have better idea if this was the case.(CCed) >>> >>> That is exactly the pattern. The driver runs out of clusters but they >>> eventually get consumed and freed although the driver refuses to process >> any >>> new frames. It is, on the other hand, perfectly capable of sending out >>> packets. >>> >> >> Ok, this clearly indicates igb(4) failed to refill RX buffers since >> you can still send frames. I'm not sure whether igb(4) controllers >> could be configured to generate no RX buffer interrupts but that >> interrupt would be better suited to trigger RX refilling than timer >> based refilling. Since igb(4) keeps track of available RX buffers, >> igb(4) can selectively enable that i
Re: [SCTP] ICMP unreachable message reenables data transmit
On Apr 30, 2011, at 9:11 AM, Schoch Christian wrote: > During a measurement with CMT-SCTP and PF i figured out, that sometimes a > ICMP Destination unreachable message triggers a message transmission on an > inactive data path that has been primary before. > > It looks as the ICMP message is reseting the inactive state back to active > without reseting RTO. > > This behavior is triggered by a returning heartbeat message when no ICMP > unreachable by data is sent quite before. > > Test system are two multi-homed hosts with FreeBSD8.1 and a WANem host > between. > > A wireshark log can be provided on demand (quite large). Hi Christian, any chance to upgrade the FreeBSD machines to head or to use newer SCTP sources, which I could provide? It would require a recompilation of the kernel... Are you using IPv4 or IPv6? Best regards Michael > > Regards, > Schoch Christian > ___ > 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: [SCTP] ICMP unreachable message reenables data transmit
On Apr 30, 2011, at 12:15 PM, Schoch Christian wrote: > > Zitat von Michael Tüxen : > >> On Apr 30, 2011, at 9:11 AM, Schoch Christian wrote: >> >>> During a measurement with CMT-SCTP and PF i figured out, that sometimes a >>> ICMP Destination unreachable message triggers a message transmission on an >>> inactive data path that has been primary before. >>> >>> It looks as the ICMP message is reseting the inactive state back to active >>> without reseting RTO. >>> >>> This behavior is triggered by a returning heartbeat message when no ICMP >>> unreachable by data is sent quite before. >>> >>> Test system are two multi-homed hosts with FreeBSD8.1 and a WANem host >>> between. >>> >>> A wireshark log can be provided on demand (quite large). >> Hi Christian, >> >> any chance to upgrade the FreeBSD machines to head or to use newer >> SCTP sources, which I could provide? It would require a recompilation >> of the kernel... > > It is possible, but the results could be provided not until next week > if a reboot is necessary. > I can use any sources you could provide me since nothing else is done at this > systems. OK, but maybe I can try to understand what is going on. How many paths do you have? One is inactive, but was primary, so it is confirmed. On another one, you get an ICMP (which one? Port unreachable, host unreachable, ...). Do you have more than two paths? The ICMP message would not reset the RTO, since you need an ACKed TSN or a HB-ACK to to that. Since it is inactive, it is missing these. Sending on an inactive path is OK, as soon as you enter the dormant state, which means all your paths are inactive. Are you using the PF support for CMT? Best regards Michael > >> >> Are you using IPv4 or IPv6? >> > > IPv4 > > >> Best regards >> Michael >>> >>> Regards, >>> Schoch Christian >>> ___ >>> 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" >> > > ___ 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: [SCTP] ICMP unreachable message reenables data transmit
On May 1, 2011, at 1:10 PM, Schoch Christian wrote: >> On Apr 30, 2011, at 12:15 PM, Schoch Christian wrote: >>> On Apr 30, 2011, at 9:11 AM, Schoch Christian wrote: > During a measurement with CMT-SCTP and PF i figured out, that sometimes a > ICMP Destination unreachable message triggers a message transmission on > an inactive data path that has been primary before. > > It looks as the ICMP message is reseting the inactive state back to > active without reseting RTO. > > This behavior is triggered by a returning heartbeat message when no ICMP > unreachable by data is sent quite before. > > Test system are two multi-homed hosts with FreeBSD8.1 and a WANem host > between. > > A wireshark log can be provided on demand (quite large). Hi Christian, any chance to upgrade the FreeBSD machines to head or to use newer SCTP sources, which I could provide? It would require a recompilation of the kernel... >>> >>> It is possible, but the results could be provided not until next week >>> if a reboot is necessary. >>> I can use any sources you could provide me since nothing else is done at >>> this systems. >> OK, but maybe I can try to understand what is going on. >> >> How many paths do you have? One is inactive, but was primary, so it >> is confirmed. On another one, you get an ICMP (which one? Port unreachable, >> host unreachable, ...). Do you have more than two paths? > > Setup looks like this: > > cut--- > Host AWANem Host B > -- > > Transfer is running on both path from A to B till the primary link is cut > between WANem and the receiver and the whole transfer switches to the second > path. The ICMP message (Host not reachable with a Heartbeat as attachment) is > received on the primary interface from WANem host. OK, understood. > > As I tested this morning, the primary path is switching to unreachable due to > the ICMP message but should be in this state quite before by exceeding > path.max_retrans. > So this ICMP message does two things: > - Set the primary path to unreachable > - Triggers something to retry data transfer on the primary path. After looking at the tracefile, I somewhat agree. * Do you see something like ICMP (thresh ??/??) takes interface ?? down on the console? This would be printed if the ICMP takes the path to unreachable? (It should also be in /var/log/messages) * If the path is already unreachable, nothing should happen in response to the ICMP message. So the question is: Is the path unreachable before the ICMP message is received? Is your application monitoring the SCTP notification? What about the above printout from the kernel? Best regards Michael > >> The ICMP message would not reset the RTO, since you need an ACKed TSN >> or a HB-ACK to to that. Since it is inactive, it is missing these. >> >> Sending on an inactive path is OK, as soon as you enter the dormant >> state, which means all your paths are inactive. >> > Transfer is still running on second link which is active. That sounds good. > >> Are you using the PF support for CMT? > > Yes, but without NR-SACK and DAC. OK. > > I uploaded the pcap file to: > http://37116.vs.webtropia.com/cmt_2.pcap That was helpful! > > Best regards, > Christian > >> >> Best regards >> Michael >>> Are you using IPv4 or IPv6? >>> >>> IPv4 >>> >>> Best regards Michael > > Regards, > Schoch Christian > ___ > 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" >>> >>> >> >> > > > ___ 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: [SCTP] ICMP unreachable message reenables data transmit
On May 1, 2011, at 7:00 PM, Schoch Christian wrote: > Zitat von Michael Tüxen: > >> On May 1, 2011, at 1:10 PM, Schoch Christian wrote: >> >>>> On Apr 30, 2011, at 12:15 PM, Schoch Christian wrote: >>>>> >>>>>> On Apr 30, 2011, at 9:11 AM, Schoch Christian wrote: >>>>>> >>>>>>> During a measurement with CMT-SCTP and PF i figured out, that sometimes >>>>>>> a ICMP Destination unreachable message triggers a message transmission >>>>>>> on an inactive data path that has been primary before. >>>>>>> >>>>>>> It looks as the ICMP message is reseting the inactive state back to >>>>>>> active without reseting RTO. >>>>>>> >>>>>>> This behavior is triggered by a returning heartbeat message when no >>>>>>> ICMP unreachable by data is sent quite before. >>>>>>> >>>>>>> Test system are two multi-homed hosts with FreeBSD8.1 and a WANem host >>>>>>> between. >>>>>>> >>>>>>> A wireshark log can be provided on demand (quite large). >>>>>> Hi Christian, >>>>>> >>>>>> any chance to upgrade the FreeBSD machines to head or to use newer >>>>>> SCTP sources, which I could provide? It would require a recompilation >>>>>> of the kernel... >>>>> >>>>> It is possible, but the results could be provided not until next week >>>>> if a reboot is necessary. >>>>> I can use any sources you could provide me since nothing else is done at >>>>> this systems. >>>> OK, but maybe I can try to understand what is going on. >>>> >>>> How many paths do you have? One is inactive, but was primary, so it >>>> is confirmed. On another one, you get an ICMP (which one? Port unreachable, >>>> host unreachable, ...). Do you have more than two paths? >>> >>> Setup looks like this: >>> >>> cut--- >>> Host AWANem Host B >>> -- >>> >>> Transfer is running on both path from A to B till the primary link is cut >>> between WANem and the receiver and the whole transfer switches to the >>> second path. The ICMP message (Host not reachable with a Heartbeat as >>> attachment) is received on the primary interface from WANem host. >> OK, understood. >>> >>> As I tested this morning, the primary path is switching to unreachable due >>> to the ICMP message but should be in this state quite before by exceeding >>> path.max_retrans. >>> So this ICMP message does two things: >>> - Set the primary path to unreachable >>> - Triggers something to retry data transfer on the primary path. >> After looking at the tracefile, I somewhat agree. >> * Do you see something like >> ICMP (thresh ??/??) takes interface ?? down >> on the console? This would be printed if the ICMP takes the >> path to unreachable? (It should also be in /var/log/messages) >> * If the path is already unreachable, nothing should happen >> in response to the ICMP message. >> > 08:04:18 kernel: ICMP (thresh 2/3) takes interface 0xc4e20510 down > Same timestamp as the faulty start in the tracefile. > >> So the question is: Is the path unreachable before the ICMP message >> is received? > Due to the timely difference between first retransmission and ICMP message it > should be in unavailable state. But it seams that too many retransmission > occur and the ICMP message is moving the path to unavailable state. > > I picked my eyes to the RTO of primary path and could figure out the > following: > > inital state: rto.min = 100ms > RTO = 100ms > > after cutting the link: > RTO rises to 200ms and 400ms as expected but not higher (rto.max=6) > > Another test with path_rxt_max = 1 worked as expected. > > So I assume some problems with the retransmission counter when larger than 1 > (something like count = 1 instead of count >= 1) > >> Is your application monitoring the SCTP notification? >> What about the above printout from the kernel? > > Yes, the notifications are monitored and logged (sctp_menu) - the > notification for SCTP_PEER_ADDR_CHANGE comes right after ICMP. OK, it all makes sense using this information after looking at the 8.1 source code. They problem should also be in HEAD. What is going on:
Checksum offloading
Dear all, I'm currently analyzing how TCP/UDP checksum offloading works to find the best way to add SCTP checksum offloading. sys/mbuf.h has constants: #define CSUM_IP 0x0001 /* will csum IP */ #define CSUM_TCP0x0002 /* will csum TCP */ #define CSUM_UDP0x0004 /* will csum UDP */ which are used to signal which offloading is supported by the drive. But, if I understand the code correctly, this only applies to UDP/IPv4 and TCP/IPv4. What about IPv6? Would this require flags like CSUM_TCP6 and CSUM_UDP6 to signal that also offloading of UDP/IPv6 and TCP/IPv6 is supported? I'm asking this because we want to add CRC offloading for SCTP/IPv4 and SCTP/IPv6. We could only add one flag CSUM_SCTP and use it for IPv4 and IPv6 ar two flags CSUM_SCTP4 and CSUM_SCTP6... Best regards Michael ___ 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: SCTP : problems in sending ASCONF chunks
Hi, are both machines (T and you PC) running FreeBSD? Best regards Michael On Dec 29, 2008, at 12:33 PM, > wrote: Hi all, I have been working with SCTP and more specifically with the mobility features of SCTP at my work. Basically, I have been trying to use SCTP to perform handover tests between 2 separate Wifi networks. I use IPv6 for all my tests. I have a local LAN (wired-network), on which I have 3 machines, one of them is the machine I use to communicate with for the tests (I'll call it T to make things simple), and the other two are used as Wifi Access Points (say Wifi1 and Wifi2 respectively). Since I work with IPv6, I set up both Access Points to send Router Advertisement messages periodically (minimum of 3 seconds, maximum of 4 seconds). That way I can have automatic address reconfiguration when I connect to either of the access points. The aim of my tests is to use a PC, connect to Wifi1 (for example), launch an SCTP association with T (T sends data to my PC), and then perform a handover on Wifi2. I do make address reconfiguration during the handover process. The important point is that I work with only ONE address on my network interface. Before I start my tests, I set the following sysctl parameters : # sysctl -w net.inet.sctp.mobility_base=1 # sysctl -w net.inet.sctp.mobility_fasthandoff=1 # sysctl -w net.inet.sctp.debug=0x00f301f0 (that is to dump messages in /var/log/messages) net.inet.sctp.auto_asconf is set to 1 by default. I use FreeBSD 7.0 on my PC, I don't know if that is extremely useful but I'm trying to be thorough. This is the script I use to perform handover : ifconfig rum0 inet6 delete ifconfig rum0 ssid route del -inet6 default rtsol rum0 If I'm not mistaken, the PC should have sent an ASCONF chunk to perform dynamic address reconfiguration. However what I observed is that nothing happens. No ASCONF chunks are sent, and therefore, T doesn't ever know that it should send data on the PC's newly acquired address. I tried to investigate the problem myself, by adding some debug logs in the sctp source code (to see which functions are called during the handover process), and it seems as if the kernel doesn't ever add an ASCONF chunk to send in its queue... But that's just my understanding of the problem... I looked up in the CVS repository for answers, and to see the various changes that were gradually brought on the code. There, I noticed that on the revision dating 24th July 2007, changes were made for dynamic address reconfiguration : "Change behaviour so that when the last address is deleted (auto-asconf on a boudall endpoint) no action is taken until an address is added ; at that time an ASCONF add+delete is sent (if the asoc is still up)" In my humble opinion, this is exactly the case that corresponds to my handover scenario. But I just haven't been able to successfully perform it because I don't seem to send any ASCONF chunk. I'm struggling to understand why I do not see any ASCONF chunk sent. If it can help, I'm also attaching links to the kind of debug logs I got when performing a handover test. This is the kind of debug logs that I got : http://www.divshare.com/download/6200509-560 This is another debug logfile, but with my own debug logs added in the sctp source code : http://www.divshare.com/download/6200504-2e9 Many thanks for your work, and I hope someone will be able to help and shed some light on this problem :-) Aman Jassal ___ 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: SCTP : problems in sending ASCONF chunks
Hi Aman, I'm not that familiar with the Linux box configuration. If you look at the INIT/INIT-ACK exchange, does the Linux box support ASCONF and the SCTP-AUTH extension? Both are required... Best regards Michael On Dec 29, 2008, at 2:36 PM, > wrote: Hello M.Tüxen, No, only the PC is running under FreeBSD 7.0. T is running under Linux (kernel version is 2.6.21 and the distribution used is Fedora Core 7). SCTP is running on T thanks to the lksctp implementation, we loaded the sctp module on it and made the necessary configurations so that it is loaded at boot time. Also, I enable net.sctp.addip_enable=1 on T, just in case, I'm not exactly sure if it has an effect on my tests. Kind regards Aman Jassal -Message d'origine- De : Michael Tüxen [mailto:michael.tue...@lurchi.franken.de] Envoyé : lundi 29 décembre 2008 14:09 À : zze-Abac JASSAL A ext RD-RESA-ISS Cc : freebsd-net@freebsd.org; DAOUD TRIKI Khadija RD-RESA-ISS Objet : Re: SCTP : problems in sending ASCONF chunks Hi, are both machines (T and you PC) running FreeBSD? Best regards Michael On Dec 29, 2008, at 12:33 PM,> wrote: Hi all, I have been working with SCTP and more specifically with the mobility features of SCTP at my work. Basically, I have been trying to use SCTP to perform handover tests between 2 separate Wifi networks. I use IPv6 for all my tests. I have a local LAN (wired-network), on which I have 3 machines, one of them is the machine I use to communicate with for the tests (I'll call it T to make things simple), and the other two are used as Wifi Access Points (say Wifi1 and Wifi2 respectively). Since I work with IPv6, I set up both Access Points to send Router Advertisement messages periodically (minimum of 3 seconds, maximum of 4 seconds). That way I can have automatic address reconfiguration when I connect to either of the access points. The aim of my tests is to use a PC, connect to Wifi1 (for example), launch an SCTP association with T (T sends data to my PC), and then perform a handover on Wifi2. I do make address reconfiguration during the handover process. The important point is that I work with only ONE address on my network interface. Before I start my tests, I set the following sysctl parameters : # sysctl -w net.inet.sctp.mobility_base=1 # sysctl -w net.inet.sctp.mobility_fasthandoff=1 # sysctl -w net.inet.sctp.debug=0x00f301f0 (that is to dump messages in /var/log/messages) net.inet.sctp.auto_asconf is set to 1 by default. I use FreeBSD 7.0 on my PC, I don't know if that is extremely useful but I'm trying to be thorough. This is the script I use to perform handover : ifconfig rum0 inet6 delete ifconfig rum0 ssid route del -inet6 default rtsol rum0 If I'm not mistaken, the PC should have sent an ASCONF chunk to perform dynamic address reconfiguration. However what I observed is that nothing happens. No ASCONF chunks are sent, and therefore, T doesn't ever know that it should send data on the PC's newly acquired address. I tried to investigate the problem myself, by adding some debug logs in the sctp source code (to see which functions are called during the handover process), and it seems as if the kernel doesn't ever add an ASCONF chunk to send in its queue... But that's just my understanding of the problem... I looked up in the CVS repository for answers, and to see the various changes that were gradually brought on the code. There, I noticed that on the revision dating 24th July 2007, changes were made for dynamic address reconfiguration : "Change behaviour so that when the last address is deleted (auto-asconf on a boudall endpoint) no action is taken until an address is added ; at that time an ASCONF add+delete is sent (if the asoc is still up)" In my humble opinion, this is exactly the case that corresponds to my handover scenario. But I just haven't been able to successfully perform it because I don't seem to send any ASCONF chunk. I'm struggling to understand why I do not see any ASCONF chunk sent. If it can help, I'm also attaching links to the kind of debug logs I got when performing a handover test. This is the kind of debug logs that I got : http://www.divshare.com/download/6200509-560 This is another debug logfile, but with my own debug logs added in the sctp source code : http://www.divshare.com/download/6200504-2e9 Many thanks for your work, and I hope someone will be able to help and shed some light on this problem :-) Aman Jassal ___ 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: SCTP : problems in sending ASCONF chunks
Hi Aman, comments in-line. Best regards Michael On Dec 29, 2008, at 6:12 PM, > wrote: Hello M.Tüxen, I performed a quick test and at the INIT/INIT-ACK exchange, I noticed the following : - In the INIT chunk, the Supported Extensions Parameter field indicates that ASCONF, ASCONF-ACK, FORWARD-TSN, PKTDROP, STREAM_RESET and AUTH are supported OK. That is the FreeBSD box. - In the INIT-ACK chunk, there is no field indicating that any of the chunks listed above are supported... So it does not support ASCONF and AUTH. At least on a Fedora 9 box you need to enable ADD-IP by setting the sysctl variable net.sctp.addip_enable to 1. To enable SCTP-AUTH you need to set the sysctl variable net.sctp.auth_enable to 1. I'm not sure whether the Linux box support SCTP-AUTH or not... So the second step might not work. If this is the case you can disable the AUTH requirement for ASCONF chunks by setting on the FreeBSD box the sysctl variable net.inet.sctp.asconf_auth_nochk to 1 Let me know if this works... I didn't think about looking in this before >_< Since there is no indication given to my PC, perhaps my PC assumes that T doesn't support ASCONF, ASCONF-ACK, FORWARD-TSN, PKTDROP, STREAM_RESET and AUTH. Correct. At least some of the extension are not enabled. Could it be that, because it doesn't see any Supported Extensions Parameter field in the INIT-ACK, my PC doesn't try to send any ASCONF chunk ?? Do we absolutely need to have the ASCONF, ASCONF-ACK and AUTH parameters in the Supported Extensions Parameter, in both the INIT and the INIT-ACK chunks, to have the possibility of sending an ASCONF chunk ? In principle, yes! You can work around the AUTH chunks as indicated above, but this violates the specification and is only supported to interwork with legacy implementations. Kind regards Aman Jassal -Message d'origine- De : Michael Tüxen [mailto:michael.tue...@lurchi.franken.de] Envoyé : lundi 29 décembre 2008 16:49 À : zze-Abac JASSAL A ext RD-RESA-ISS Cc : freebsd-net@freebsd.org; DAOUD TRIKI Khadija RD-RESA-ISS Objet : Re: SCTP : problems in sending ASCONF chunks Hi Aman, I'm not that familiar with the Linux box configuration. If you look at the INIT/INIT-ACK exchange, does the Linux box support ASCONF and the SCTP-AUTH extension? Both are required... Best regards Michael On Dec 29, 2008, at 2:36 PM,> wrote: Hello M.Tüxen, No, only the PC is running under FreeBSD 7.0. T is running under Linux (kernel version is 2.6.21 and the distribution used is Fedora Core 7). SCTP is running on T thanks to the lksctp implementation, we loaded the sctp module on it and made the necessary configurations so that it is loaded at boot time. Also, I enable net.sctp.addip_enable=1 on T, just in case, I'm not exactly sure if it has an effect on my tests. Kind regards Aman Jassal -Message d'origine- De : Michael Tüxen [mailto:michael.tue...@lurchi.franken.de] Envoyé : lundi 29 décembre 2008 14:09 À : zze-Abac JASSAL A ext RD-RESA-ISS Cc : freebsd-net@freebsd.org; DAOUD TRIKI Khadija RD-RESA-ISS Objet : Re: SCTP : problems in sending ASCONF chunks Hi, are both machines (T and you PC) running FreeBSD? Best regards Michael On Dec 29, 2008, at 12:33 PM, wrote: Hi all, I have been working with SCTP and more specifically with the mobility features of SCTP at my work. Basically, I have been trying to use SCTP to perform handover tests between 2 separate Wifi networks. I use IPv6 for all my tests. I have a local LAN (wired-network), on which I have 3 machines, one of them is the machine I use to communicate with for the tests (I'll call it T to make things simple), and the other two are used as Wifi Access Points (say Wifi1 and Wifi2 respectively). Since I work with IPv6, I set up both Access Points to send Router Advertisement messages periodically (minimum of 3 seconds, maximum of 4 seconds). That way I can have automatic address reconfiguration when I connect to either of the access points. The aim of my tests is to use a PC, connect to Wifi1 (for example), launch an SCTP association with T (T sends data to my PC), and then perform a handover on Wifi2. I do make address reconfiguration during the handover process. The important point is that I work with only ONE address on my network interface. Before I start my tests, I set the following sysctl parameters : # sysctl -w net.inet.sctp.mobility_base=1 # sysctl -w net.inet.sctp.mobility_fasthandoff=1 # sysctl -w net.inet.sctp.debug=0x00f301f0 (that is to dump messages in /var/log/messages) net.inet.sctp.auto_asconf is set to 1 by default. I use FreeBSD 7.0 on my PC, I don't know if that is extremely useful but I'm trying to be thorough. This is the script I use to perform handover : ifconfig rum0 inet6 delete ifconfig rum0 ssid route del -inet6 default rtsol rum0 If I'm not
SCTP related issue with recent ARP changes?
Dear all, I'm running the current CVS version of FreeBSD 8 in a virtual machine using VMWare 2.0.1 on a Mac (not sure if this is relevant) and bridged networking having an em interface on the virtual machine. I'm using a similar setup with older FreeBSD machines and they are running fine. Loopback communication based on UDP, TCP, SCTP or ICMP works fine. Communicating with other hosts using UDP, TCP or ICMP works fine. Communicating with other hosts using SCTP does not work. The SCTP stack calls ip_output() and an ARP request for the correct destination IP address is send out. A corresponding ARP reply is visible in Wireshark (running on the FreeBSD 8 box) and looks good. However, the corresponding SCTP packet it never sent out. I'm not sure, but this might be related to the recent ARP changes. Is there anything required from the transport layer to be done when calling ip_output() that was not required before? Best regards Michael ___ 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: SCTP related issue with recent ARP changes?
Hi Qing, I have tested your patch and it works! Thanks you very much for your help. Best regards Michael On Jan 2, 2009, at 11:15 PM, Li, Qing wrote: Hi Michael, The SCTP problem you were having was attributed to the arp-v2 changes. The reason TCP and UDP works well is because the TCP and UDP modules does not supply a route entry when calling ip_output(). Consequently in ip_output() the destination (sockaddr) was reinitialized and the sin_port field is 0. The destination sockaddr supplied in the route entry from the SCTP module has the actual port value in it. The new L2 search was (initially) written as a generic function. So the L3 address comparison was performed using bcmp() of sockaddr_len bytes. The L2 entry was created with a sockaddr object that includes the port value, however, on ARP input the port value does not apply. The mismatch in port value causes the ARP lookup to fail and the SCTP connection never complete its negotiation. Please apply the patch for IPv4 in my home directory at http://people.freebsd.org/~qingli/in.c.diff I did the basic testing using the programs you gave me and now the client connects successful and completes the transfer. I also verified the packets in wireshark trace. Please let me know if this patch fixes your SCTP problems. Thank you for your help. -- Qing -Original Message- From: owner-freebsd-curr...@freebsd.org [mailto:owner-freebsd- curr...@freebsd.org] On Behalf Of Li, Qing Sent: Thursday, January 01, 2009 12:17 PM To: Michael Tüxen; FreeBSD Net Cc: qin...@freebsd.org; curr...@freebsd.org Subject: RE: SCTP related issue with recent ARP changes? Hi Michael, Your problem could be related to the recent ARP changes. I will investigate further to confirm. Thanks, -- Qing -Original Message- From: owner-freebsd-...@freebsd.org on behalf of Michael Tüxen Sent: Thu 1/1/2009 8:59 AM To: FreeBSD Net Subject: SCTP related issue with recent ARP changes? Dear all, I'm running the current CVS version of FreeBSD 8 in a virtual machine using VMWare 2.0.1 on a Mac (not sure if this is relevant) and bridged networking having an em interface on the virtual machine. I'm using a similar setup with older FreeBSD machines and they are running fine. Loopback communication based on UDP, TCP, SCTP or ICMP works fine. Communicating with other hosts using UDP, TCP or ICMP works fine. Communicating with other hosts using SCTP does not work. The SCTP stack calls ip_output() and an ARP request for the correct destination IP address is send out. A corresponding ARP reply is visible in Wireshark (running on the FreeBSD 8 box) and looks good. However, the corresponding SCTP packet it never sent out. I'm not sure, but this might be related to the recent ARP changes. Is there anything required from the transport layer to be done when calling ip_output() that was not required before? Best regards Michael ___ 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: A query regarding SCTP congestion control
Hi Sazzad, what is the value of the from field i the structure sctp_cwnd_log? Best reards Michael On Jan 23, 2009, at 1:16 AM, Rahman, Md Sazzadur wrote: Hi Randall, Thanks for your suggestions. I could collect congestion window data from SCTP sender using SCTP_LOCAL_TRACE_BUF on FreeBSD7.1 kernel using the tools you provided (dump_apple_log.c, prtcwndlog.c etc.). Now, in the log, I found that tsn (Transmission Sequence Number) never changes and remains fixed which is not supposed to happen, I believe. Do you have any idea what could go wrong? For example, in the log below, tsn is always 28170ae0. //-From Log--- 2.162922 1543161849724545 Network:0xc463aaf0 cwnd:13063 flight: 12762 pq:f4f72484 Log from a Send tsn:28170ae0 (sendcnt:191,strcnt: 191) 2.200947 1543161849753090 Network:0xc463aaf0 cwnd:13063 flight: 14180 pq:f4f72484 Log from a Send tsn:28170ae0 (sendcnt:191,strcnt: 191) .. . 2592.987776 1543168861292865 Network:0xc463aaf0 cwnd:13063 flight: 14180 pq:f4f72484 Log from a Send tsn:28170ae0 (sendcnt:191,strcnt: 191) //-- Steps I have followed: //-- 1. Recompiled FreeBSD7.1 kernel by enabling SCTP_LOCAL_TRACE_BUF #define SCTP_LOCAL_TRACE_BUF 1 2. Enalble desired loging using sysctl; Sysctl -w "net.inet.sctp.log_level=0x0004 3. Run application that sends SCTP data to the network 4. ./Dump_apple_log > data.txt 5. ./Prtcwdlog -l data.txt> cwnd.txt //-- I have attached the log file herewith this mail. It would be great if you can give me any hint to resolve this issue. Thanks, Sazzad -Original Message- From: Randy Stewart [mailto:rand...@lakerest.net] Sent: Thursday, August 28, 2008 6:39 AM To: sazzadur rahman Cc: freebsd-net; Atiquzzaman, Mohammed; Rahman, Md Sazzadur Subject: Re: A query regarding SCTP congestion control Remember a lot has changed between the book and now. 1) The initial window is now different 2) labc variable may influence how the cwnd responds are just 2 off the top of my head. You also may want to use a local trace buffer (as I mentioned earlier) since turning KTR on really really skew's things time wise.. its a resource pig. We added the local trace buffer for this very reason. Contact me directly if you need guidance on this. Also you may want to pick up the latest update that I just put up on www.sctp.org It gets the 7.0 stack current to 8.0's code.. .and there have been at least 1 CC fix in the last few months.. R On Jul 2, 2008, at 2:37 PM, sazzadur rahman wrote: Hello, I need to get SCTP congestion window data for research purpose. I collected cwnd data from SCTP sender running on FreeBSD 7.0 machine by using KTR kernel log. After that, I tried to plot cwnd vs. time and generated graph. But I am unable to explain the graph and it is very different compared to the graph as shown in the book "Stream Control Transmission Protocol (SCTP)", a reference guide by Randall R. Stewart, page 187 and TCP congestion window. An typical entry from the log looks like: 749199232185105 Net:0xc7703000 at cwnd_event (SACK) cwnd:25140 flight:0 pq:0 atpc:72 needpc:235 (tsn:0,sendcnt:191,strcnt:191) I have used 749199232185105 in x axis as time and cwnd:25140 in y axis. I have attached the image file of the graph herewith this mail. From the log, I found that cwnd varies very frequently accross time. Does anyone have any idea regarding this issue? Please let me know if you have any questions further. Thanks in advance. Best regards, Md Sazzadur Rahman Graduate Student, School of Computer Science, University of Oklahoma, Norman, Oklahoma, USA Steps for getting kernel log -- 1. Add options: options KTR options KTR_ENTRIES=65536 options KTR_MASK=KTR_SUBSYS 2. Recompile kernel config CUSTOM_KERNEL_9_6 cd ../compile/ CUSTOM_KERNEL_9_6 make cleandepend;make depend; make all install 3. Tried to enable trace point by: Sysctl -w "net.inet.sctp.log_level=0x0004" 4. run SCTP sender. 5. pull out data: Ktrdump -q -t -o file_name Prtcwndlog -l filename > cwnd.txt --- On Wed, Apr 16, 2008 at 9:03 AM, Randall Stewart wrote: Rahman, Md Sazzadur wrote: Hi, I would like to get the values of SCTP congestion control algorithm variables (cwnd, ssthresh, flightsize and pba) from any SCTP based application in runtime for research purpose. Does any API exist in SCTP for that? Do I need to dig the SCTP code in kernel to get the values? There is a socket option to get the cwnd. However, I think what you really want is some of the researchish tracing stuff that SCTP provides. You can actually get a real time trace of the cwnd/flight etc via the various logging functions. You basic
Re: SCTP, possible bug in peer authentication key
Hi Yann,
very good catch! You are right.
I have committed your patch to Randalls repository, so it will
show up in the FreeBSD sources soon (next time he syncs them)...
Best regards
Michael
On Jan 28, 2009, at 8:51 PM, Yann WANWANSCAPPEL wrote:
Hi all,
I think I found a bug in the SCTP authentication code, in
sctp_load_addresses_from_init() in sctp_pcb.c
keylen = sizeof(*p_random) + random_len + sizeof(*chunks) +
num_chunks +
sizeof(*hmacs) + hmacs_len;
The keylen calculation assumes the Chunk List Parameter (CHUNKS)
vl-param was present in the received INIT packet, which can be false
if
peer SCTP does not require any chunk to be authenticated (this
typically
occurs if peer does not support ASCONF).
From RFC 4895, 6.1
* An SCTP endpoint has a list of chunks it only accepts if they are
* received in an authenticated way. This list is included in the INIT
* and INIT-ACK, and MAY be omitted if it is empty. Since this list
* does not change during the lifetime of the SCTP endpoint there is no
* problem in case of INIT collision.
This case is properly handled later in the build of the key
/* append in the AUTH chunks */
if (chunks != NULL) {
.
}
I think the calculated keylen should be something like this :
keylen = sizeof(*p_random) + random_len + sizeof(*hmacs) + hmacs_len;
if (chunks != NULL) {
keylen += sizeof(*chunks) + num_chunks
}
This problem results in authenticated packets sent from peer SCTP to
be
discarded.
The problem does not occurs if peer SCTP is modified to send an empty
Chunk List Parameter, (eg num_chunks = 0 in the decoding).
Br,
Yann
___
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: SCTP, possible bug in peer authentication key
Hi Peter,
good catch!
Best regards
Michael
On Jan 29, 2009, at 6:29 PM, Peter Lei wrote:
There's a corresponding change that is needed for pulling the auth
info
out of the cookie for the other direction (i.e. server side
handling). I've
committed that into the SCTP project repo, and should also get in with
Randall's next commit.
--peter
On Jan 29, 2009, at 2:23 AM, Michael Tüxen wrote:
Hi Yann,
very good catch! You are right.
I have committed your patch to Randalls repository, so it will
show up in the FreeBSD sources soon (next time he syncs them)...
Best regards
Michael
On Jan 28, 2009, at 8:51 PM, Yann WANWANSCAPPEL wrote:
Hi all,
I think I found a bug in the SCTP authentication code, in
sctp_load_addresses_from_init() in sctp_pcb.c
keylen = sizeof(*p_random) + random_len + sizeof(*chunks) +
num_chunks +
sizeof(*hmacs) + hmacs_len;
The keylen calculation assumes the Chunk List Parameter (CHUNKS)
vl-param was present in the received INIT packet, which can be
false if
peer SCTP does not require any chunk to be authenticated (this
typically
occurs if peer does not support ASCONF).
From RFC 4895, 6.1
* An SCTP endpoint has a list of chunks it only accepts if they are
* received in an authenticated way. This list is included in the
INIT
* and INIT-ACK, and MAY be omitted if it is empty. Since this list
* does not change during the lifetime of the SCTP endpoint there
is no
* problem in case of INIT collision.
This case is properly handled later in the build of the key
/* append in the AUTH chunks */
if (chunks != NULL) {
.
}
I think the calculated keylen should be something like this :
keylen = sizeof(*p_random) + random_len + sizeof(*hmacs) +
hmacs_len;
if (chunks != NULL) {
keylen += sizeof(*chunks) + num_chunks
}
This problem results in authenticated packets sent from peer SCTP
to be
discarded.
The problem does not occurs if peer SCTP is modified to send an
empty
Chunk List Parameter, (eg num_chunks = 0 in the decoding).
Br,
Yann
___
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"
___
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: SCTP, possible bug in peer authentication key
Hi Matt,
Peter Lei (who wrote the AUTH code) already fixed that in Randalls CVS
server.
So it will show up when Randall syncs the repositories next time.
Thank you for pointing that out. I missed that...
Best regards
Michael
On Jan 30, 2009, at 2:37 AM, Muggeridge, Matt wrote:
I think I found a bug in the SCTP authentication code, in
sctp_load_addresses_from_init() in sctp_pcb.c
I noticed the same calculation appears in
sctp_auth.c:sctp_auth_get_cookie_params(). Does this fix also need
to be applied there?
Cheers,
Matt.
-Original Message-
From: Michael Tüxen [mailto:michael.tue...@lurchi.franken.de]
Sent: Thursday, 29 January 2009 6:23 PM
To: Yann WANWANSCAPPEL
Cc: freebsd-net@freebsd.org
Subject: Re: SCTP, possible bug in peer authentication key
Hi Yann,
very good catch! You are right.
I have committed your patch to Randalls repository, so it will show
up in the FreeBSD sources soon (next time he syncs them)...
Best regards
Michael
On Jan 28, 2009, at 8:51 PM, Yann WANWANSCAPPEL wrote:
Hi all,
I think I found a bug in the SCTP authentication code, in
sctp_load_addresses_from_init() in sctp_pcb.c
keylen = sizeof(*p_random) + random_len + sizeof(*chunks) +
num_chunks
+
sizeof(*hmacs) + hmacs_len;
The keylen calculation assumes the Chunk List Parameter (CHUNKS)
vl-param was present in the received INIT packet, which can be false
if peer SCTP does not require any chunk to be authenticated (this
typically occurs if peer does not support ASCONF).
From RFC 4895, 6.1
* An SCTP endpoint has a list of chunks it only accepts if they are
* received in an authenticated way. This list is included in the
INIT
* and INIT-ACK, and MAY be omitted if it is empty. Since this list
* does not change during the lifetime of the SCTP endpoint there is
no
* problem in case of INIT collision.
This case is properly handled later in the build of the key
/* append in the AUTH chunks */
if (chunks != NULL) {
.
}
I think the calculated keylen should be something like this :
keylen = sizeof(*p_random) + random_len + sizeof(*hmacs) + hmacs_len;
if (chunks != NULL) {
keylen += sizeof(*chunks) + num_chunks }
This problem results in authenticated packets sent from peer SCTP to
be discarded.
The problem does not occurs if peer SCTP is modified to send an empty
Chunk List Parameter, (eg num_chunks = 0 in the decoding).
Br,
Yann
___
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"
TCP performance question
Dear all,
we have used a client to do
while (1) {
send(fd, buffer, n);
}
against a discard server on a different machine. The
sender is running FreeBSD 7.1, for the receiver we
used two different machines, one running FreeBSD 7.1
another one Mac OS X 10.5.6. The machines are old,
so I do not care about the absolute numbers.
We measured the throughput for 60 seconds and different
values of n. Here is what we got:
nthroughput
500, 77716.505790
501, 77490.917999
502, 77412.961710
503, 77333.560297
504, 77801.337017
505, 77427.814392
506, 77422.640826
507, 77360.185565
508, 77607.863180
509, 77445.288161
510, 77531.083699
511, 77486.518785
512, 77908.246985
513, 68175.140109
514, 68338.332801
515, 68359.883062
516, 68640.669589
517, 68314.060835
518, 68473.051618
519, 68507.277602
520, 68930.431180
521, 68590.979508
522, 68790.924360
523, 68848.960564
524, 69091.676020
525, 68720.795262
526, 68897.330715
527, 69070.935237
528, 69421.723656
529, 68908.417372
530, 69000.914392
The question I have is he following:
Why is the throughput smaller for n > 512
than for n <= 512?
Since the result is about the same for different
receivers, this seems to be related to the sender side.
Best regards
Michael
___
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: Problems in using SCTP CMT
H Andrew, what you describe is correct. Are there actually multiple addresses changed within the INIT/INIT-ACK chunk? If yes, you have done everything correctly. The interesting thing: I also noticed that there are CMT problems on FreeBSD 8.0 Current. Randall Stewart and myself have started debugging the problem yesterday... We'll send you a notice, once we have found the problem and fixed it. Best regards Michael On Mar 23, 2009, at 3:20 AM, Andrew Chen wrote: Hi, We have some problems when we tried to send data using CMT-SCTP. Actually, we are not sure if we do enable CMT functionalities. We set up two PCs with FreeBSD-7.0. Each PC has two NICs and two IPs. One is public and the other is private. We wrote simple FTP server and client programs. On both sides, local addresses are bound as INADDR_ANY. According to http://tools.ietf.org/html/draft-ietf-tsvwg-sctpsocket-14#section-4.1.5 , if we bind INADDR_ANY and then call connect(), the multi-homing capability of SCTP is automatically enabled. Further, we also turn on sysctl states by setting sysctl net.inet.sctp.cmt_pf=1 sysctl net.inet.sctp.cmt_use_dac=1 sysctl net.inet.sctp.cmt_on_off=1 Then we start transmission and capture the traffics. Unfortunately, the captured packet shows data were transmitted on primary path and there were only heartbeat/HB ACKs on the other path. To our knowledge, to use CMT, the only things we have to do is to establish a multihomed association, and turn on the sysctl options. Can anyone point out something we did wrong or steps we missed? Thanks in advance. ___ 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: OpenSSL DTLS bug fix patches
Hi Bruce, at least one member of the OpenSSL core team (Steven) has integrated our patches regarding bug fixes in the source code. So they will be included in the next release of OpenSSL. Best regards Michael On Apr 15, 2009, at 2:36 PM, Bruce Simpson wrote: I know it's late in the 7.2 game, but does our OpenSSL maintainer know about this? http://sctp.fh-muenster.de/dtls-patches.html It would be nice to have in a release, although I'm tracking branches for anything I'm doing at the moment. JFYI, BMS ___ 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: OpenSSL DTLS bug fix patches
On Apr 16, 2009, at 2:19 AM, Bruce Simpson wrote: Michael Tüxen wrote: Hi Bruce, at least one member of the OpenSSL core team (Steven) has integrated our patches regarding bug fixes in the source code. So they will be included in the next release of OpenSSL. That's excellent news, and these fixes look good, but I was more wondering if this drop would be in FreeBSD 7.2-RELEASE :-) I know, but I wanted to make the state of the patches clear to make the decision for the port maintainer easier. Are you using DTLS? If not no biggie, I am tracking -STABLE for work. thanks, BMS ___ 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: OpenSSL DTLS bug fix patches
On Apr 16, 2009, at 12:39 PM, Bruce Simpson wrote: Michael Tüxen wrote: On Apr 16, 2009, at 2:19 AM, Bruce Simpson wrote: ... That's excellent news, and these fixes look good, but I was more wondering if this drop would be in FreeBSD 7.2-RELEASE :-) I know, but I wanted to make the state of the patches clear to make the decision for the port maintainer easier. Are you using DTLS? Not yet, but I came across these patches whilst researching TLS adaptation for SCTP. Ahh, I see. Even more interesting. If you try our DTLS/SCTP implementation, please let us know if it works for you or if you have any questions... cheers, BMS ___ 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: TCP RST question
On Jul 31, 2009, at 3:57 PM, > wrote: Hi all, I'm looking at our TCP stack and found a change that was introduced with the syncache. The original BSD code did send an RST segment when the connection timed out in SYN-RECEIVED. The TCP would retransmit the SYN+ACK several times and then give up and RST the peer. With syncache, however, our TCP doesn't send the RST anymore. It just silently discards local state. So the question is whether TCP is supposed to RST or not. Looking at RFC793 I found nothing useful. It talks about sending RSTs as response to incoming segments and it looks like TCP is never supposed to give up retransmitting. The state diagram has no line from SYN-RECEIVED to CLOSED. Stevens, on the other hand, has this line and it is labeled 'send: RST'. So the questions are: - is TCP supposed to send an RST when it times out in SYN-RECEIVED? - why was this changed (I suppose it is just one of the regressions introduced with the syn-cache). harti NB: does anybody know a good mailing list where this kind of questions can be discussed? ts...@ietf.org t...@ietf.org Best reagrds Michael ___ 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"
routing message problem
Dear all, via a bug report from Preethi I figured out that there are no RTM_NEWADDR routing messages generated when an IP address is added to an interface and there is already an address in the same network configured. This is a problem for the SCTP stack. To reproduce the problem you can sudo ifconfig em0 192.168.1.1 sudo ifconfig em0 192.168.1.2 alias and use the attached problem. It will only show the first address being added. This problem applies to FreeBSD 9.0 CURRENT and 7.2 RELEASE. Any idea how to fix the problem? Best regards Michael ___ 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: routing message problem
... I forgot to attach the program... aw.c Description: Binary data On Aug 28, 2009, at 11:00 AM, Michael Tüxen wrote: Dear all, via a bug report from Preethi I figured out that there are no RTM_NEWADDR routing messages generated when an IP address is added to an interface and there is already an address in the same network configured. This is a problem for the SCTP stack. To reproduce the problem you can sudo ifconfig em0 192.168.1.1 sudo ifconfig em0 192.168.1.2 alias and use the attached problem. It will only show the first address being added. This problem applies to FreeBSD 9.0 CURRENT and 7.2 RELEASE. Any idea how to fix the problem? Best regards Michael ___ 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: routing message problem
Hi Qing,
your patch fixes the issue.
Will it find its way into 8.0?
Will it find its way into 7.3?
Best regards
Michael
On Aug 28, 2009, at 7:24 PM, Li, Qing wrote:
Dear all,
via a bug report from Preethi I figured out that there are no
RTM_NEWADDR
routing messages generated when an IP address is added to an
interface
and there is already an address in the same network configured.
This is a problem for the SCTP stack.
To reproduce the problem you can
sudo ifconfig em0 192.168.1.1
sudo ifconfig em0 192.168.1.2 alias
and use the attached problem. It will only show the first address
being added. This problem applies to FreeBSD 9.0 CURRENT and 7.2
RELEASE.
Any idea how to fix the problem?
Please try my patch (not the final version) at
http://people.freebsd.org/~qingli/patch-8-28-rtmsg.diff
I have tested it and seems to work as expected. You should
get the notifications for both address insertion ("alias")
and deletion ("-alias").
Let me know if it's to your satisfaction.
I found a couple of other issues while looking over the code.
1. in_scrubprefix() is called unnecessarily in 2 locations
2. the loopback host route is not removed for an alias
On a related note, in.c can use some code cleanup. I think
I will do that post 8.0 release.
Thanks,
-- Qing
___
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: routing message problem
On Aug 30, 2009, at 4:08 AM, Li, Qing wrote:
Hi Michael,
your patch fixes the issue.
Will it find its way into 8.0?
Will it find its way into 7.3?
Yes, the patch will make its way into 8.0 Release and 7.3, too.
Great! Thanks a lot.
Best regards
Michael
Thanks,
-- Qing
On Aug 28, 2009, at 7:24 PM, Li, Qing wrote:
Dear all,
via a bug report from Preethi I figured out that there are no
RTM_NEWADDR
routing messages generated when an IP address is added to an
interface
and there is already an address in the same network configured.
This is a problem for the SCTP stack.
To reproduce the problem you can
sudo ifconfig em0 192.168.1.1
sudo ifconfig em0 192.168.1.2 alias
and use the attached problem. It will only show the first address
being added. This problem applies to FreeBSD 9.0 CURRENT and 7.2
RELEASE.
Any idea how to fix the problem?
Please try my patch (not the final version) at
http://people.freebsd.org/~qingli/patch-8-28-rtmsg.diff
I have tested it and seems to work as expected. You should
get the notifications for both address insertion ("alias")
and deletion ("-alias").
Let me know if it's to your satisfaction.
I found a couple of other issues while looking over the code.
1. in_scrubprefix() is called unnecessarily in 2 locations
2. the loopback host route is not removed for an alias
On a related note, in.c can use some code cleanup. I think
I will do that post 8.0 release.
Thanks,
-- Qing
___
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: SCTP : problems in sending ASCONF chunks
Hi Gaurav, you might want to discuss this on the Linux SCTP mailing list, not on the FreeBSD net mailing list. You find Linux experts there... Best regards Michael On Dec 17, 2009, at 8:17 AM, Gaurav Bhateja wrote: > Hi Vlad, > > I would really appreciate if you could help me out on this issue. > > I came to know about this email ID from the link > http://lists.freebsd.org/pipermail/freebsd-net/2009-January/020683.html > > I am getting error, "Operation not permitted" when setting peer primary > address from server. > I am using linux version 2.6-15(client) --- 2.6.21(server) > > Would there be a problem in dynamically configuring primary address using > sctp options, SCTP_PRIMARY_ADDR and SCTP_SET_PEER_PRIMARY_ADDR for these > linux versions? > > You have suggested that its better to use linux version - 2.6-25. (It is > difficult for us to switch to these versions due to license issues) > > Could you provide is any other way to solve this issue. > > > Regrds, > Gaurav > > > > > "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" > ___ 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: igb interrupt moderation
Hi Barney, Hi Jack,
some comments and some more questions inside...
Best regards
Michael
On Jan 2, 2010, at 8:42 PM, Barney Cordoba wrote:
> Jack,
>
> I'm trying to get some clarification on differences I'm finding between
> the 82575 and 82576 parts with respect to interrupt moderation. The spec
> I have for the 82576 (82576_Datasheet_v2p1.pdf) indicates that the
I'm only commenting 82576. You can get rev 2.41 from intels website...
>
> ITR algorithm is different than the one used (I don't have one of the
> secret copies of the 82575 spec). The algorithm shown is
>
> interrupts/sec = 1/(2 * 10-6sec x interval) (page 295, Section 7.3.4)
>
> which is clearly wrong from practice. I have an 82576 (device id 10C9)
If you look at section 8.8.12, you find other formulas...
Jack: Which ones are correct?
> if I use the 125d setting in the example get just under 32000 interrupts
> per second. Clearly your code doesnt implement this, nor do you have
> different settings for the 82575 and 82576 parts. So I assume that the
> same formula for the em parts hold for the igb parts, and that the
> datasheet is wrong?
>
> There does seem to be a slight difference. The setting that gets 1000
> ints/second on the 82575 generates about 1020 on the 82576. Not a big
> deal but I wonder why there's a difference? Is the reference clock for
> these something that may not be fixed and could vary from board to
> board? Note that both devices are on the same MB.
>
> Also, it seems that settings to EITR over 32767 wrap on the 82576 (for
> example writing 32768 to EITR is the same as writing a 1). So the minimum
> setting on the 82576 is around 125 ints/second. The 82575 can accept
> values up the 65535 before wrapping.
Hmm, looking at the table in 8.8.12 would suggest:
Setting it to one sets a reserved bit, but does not change the interval.
Setting it to 2^15 should set the LLI_EN bit, but does not change in interval.
Jack is setting the register to
igb_low_latency: 128
igb_ave_latency: 450
igb_bulk_latency: 1200
This would result in intervals of:
igb_low_latency: 32
igb_ave_latency: 112
igb_bulk_latency: 300
Jack: What are the corresponding interrupt rates? The spec provides different
formulas and talks about a 1us, 2us or 8us counter. Not sure what is
right...
Jack: Why are you setting bit1 (which is reserved) in the case igb_ave_latency?
And another question for Jack:
In igb_update_aim() you do
if (olditr != newitr) {
/* Change interrupt rate */
rxr->eitr_setting = newitr;
E1000_WRITE_REG(&adapter->hw, E1000_EITR(rxr->me),
newitr | (newitr << 16));
}
So why are setting the higher bits of the EITR? You are setting
igb_low_latency: the LL Counter becomes 0, the moderation counter becomes 16
igb_ave_latency: the LL Counter becomes 2, the moderation counter becomes 56
igb_bulk_latency: the LL Counter becomes 16, the moderation counter becomes 148
I really do not understand these settings. Maybe the spec is wrong? Or you do
mean
if (olditr != newitr) {
/* Change interrupt rate */
rxr->eitr_setting = newitr;
E1000_WRITE_REG(&adapter->hw, E1000_EITR(rxr->me), newitr);
}
Or do you want to preserve the counters, set the CNT_INGR bit and mean
if (olditr != newitr) {
/* Change interrupt rate */
rxr->eitr_setting = newitr;
E1000_WRITE_REG(&adapter->hw, E1000_EITR(rxr->me), 0x8000 |
newitr);
}
Could you clarify that?
>
> The 82576 document doesn't have a map of the register that I can find, so
> Im curious as to whether these observations are something I can assume is
> true across all parts and motherboards/cards, or is there some
> implementation variance that will cause these to only apply to the ones
> I happen to be testing?
>
> Thanks,
>
> Barney
>
>
>
>
> ___
> 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: igb interrupt moderation
Dear all,
I just figured out that there is a newer version of the spec
available: 2.45. Some of the issues as indicated inline
are already resolved.
Best regards
Michael
On Jan 3, 2010, at 2:55 PM, Michael Tüxen wrote:
> Hi Barney, Hi Jack,
>
> some comments and some more questions inside...
>
> Best regards
> Michael
>
> On Jan 2, 2010, at 8:42 PM, Barney Cordoba wrote:
>
>> Jack,
>>
>> I'm trying to get some clarification on differences I'm finding between
>> the 82575 and 82576 parts with respect to interrupt moderation. The spec
>> I have for the 82576 (82576_Datasheet_v2p1.pdf) indicates that the
> I'm only commenting 82576. You can get rev 2.41 from intels website...
It is really 2.45 now
>>
>> ITR algorithm is different than the one used (I don't have one of the
>> secret copies of the 82575 spec). The algorithm shown is
>>
>> interrupts/sec = 1/(2 * 10-6sec x interval) (page 295, Section 7.3.4)
>>
>> which is clearly wrong from practice. I have an 82576 (device id 10C9)
> If you look at section 8.8.12, you find other formulas...
> Jack: Which ones are correct?
The formulas is 8.8.12 are gone. Issue resolved.
>> if I use the 125d setting in the example get just under 32000 interrupts
>> per second. Clearly your code doesnt implement this, nor do you have
>> different settings for the 82575 and 82576 parts. So I assume that the
>> same formula for the em parts hold for the igb parts, and that the
>> datasheet is wrong?
>>
>> There does seem to be a slight difference. The setting that gets 1000
>> ints/second on the 82575 generates about 1020 on the 82576. Not a big
>> deal but I wonder why there's a difference? Is the reference clock for
>> these something that may not be fixed and could vary from board to
>> board? Note that both devices are on the same MB.
>>
>> Also, it seems that settings to EITR over 32767 wrap on the 82576 (for
>> example writing 32768 to EITR is the same as writing a 1). So the minimum
>> setting on the 82576 is around 125 ints/second. The 82575 can accept
>> values up the 65535 before wrapping.
> Hmm, looking at the table in 8.8.12 would suggest:
> Setting it to one sets a reserved bit, but does not change the interval.
> Setting it to 2^15 should set the LLI_EN bit, but does not change in interval.
>
> Jack is setting the register to
> igb_low_latency: 128
> igb_ave_latency: 450
> igb_bulk_latency: 1200
>
> This would result in intervals of:
> igb_low_latency: 32
> igb_ave_latency: 112
> igb_bulk_latency: 300
> Jack: What are the corresponding interrupt rates? The spec provides different
> formulas and talks about a 1us, 2us or 8us counter. Not sure what is
> right...
The interrupt rates are according to the formula in the spec
igb_low_latency: 31250
igb_ave_latency: 8929
igb_bulk_latency:
Jack: Is this right?
> Jack: Why are you setting bit1 (which is reserved) in the case
> igb_ave_latency?
Still valid.
>
> And another question for Jack:
> In igb_update_aim() you do
> if (olditr != newitr) {
> /* Change interrupt rate */
> rxr->eitr_setting = newitr;
> E1000_WRITE_REG(&adapter->hw, E1000_EITR(rxr->me),
> newitr | (newitr << 16));
> }
> So why are setting the higher bits of the EITR? You are setting
> igb_low_latency: the LL Counter becomes 0, the moderation counter becomes 16
> igb_ave_latency: the LL Counter becomes 2, the moderation counter becomes 56
> igb_bulk_latency: the LL Counter becomes 16, the moderation counter becomes
> 148
Still valid.
>
> I really do not understand these settings. Maybe the spec is wrong? Or you do
> mean
> if (olditr != newitr) {
> /* Change interrupt rate */
> rxr->eitr_setting = newitr;
> E1000_WRITE_REG(&adapter->hw, E1000_EITR(rxr->me), newitr);
> }
> Or do you want to preserve the counters, set the CNT_INGR bit and mean
> if (olditr != newitr) {
> /* Change interrupt rate */
> rxr->eitr_setting = newitr;
> E1000_WRITE_REG(&adapter->hw, E1000_EITR(rxr->me), 0x8000 |
> newitr);
> }
>
> Could you clarify that?
Still valid.
>>
>> The 82576 document doesn't have a map of the register that I can find, so
>> Im curious as to whether these observations are something I can assume is
>> true across all parts and motherboards/cards, or is there some
>> implementation variance that will cause these to only apply to the ones
>> I happen to be testing?
>>
>
Re: igb interrupt moderation
On Jan 3, 2010, at 3:28 PM, Mike Tancsa wrote: > At 08:55 AM 1/3/2010, Michael Tüxen wrote: >> Hi Barney, Hi Jack, >> >> some comments and some more questions inside... > > > Just a separate datapoint about this driver, unless I apply > > http://people.freebsd.org/~yongari/igb/igb.buf.patch6 > > the driver is not really usable for me in RELENG_8 on the dual port version > of the card Could you elaborate on what you mean by "not really usable"? Best regards Michael > >---Mike > > > > > > > Mike Tancsa, tel +1 519 651 3400 > Sentex Communications,m...@sentex.net > Providing Internet since 1994www.sentex.net > Cambridge, Ontario Canada www.sentex.net/mike > > ___ 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: igb interrupt moderation
On Jan 3, 2010, at 5:23 PM, Mike Tancsa wrote: > At 11:13 AM 1/3/2010, Michael Tüxen wrote: >> > >> > Just a separate datapoint about this driver, unless I apply >> > >> > http://people.freebsd.org/~yongari/igb/igb.buf.patch6 >> > >> > the driver is not really usable for me in RELENG_8 on the dual port >> > version of the card >> Could you elaborate on what you mean by "not really usable"? > > > Hi, >Some link state issues (getting confused about what port is up), > problems at high packet rates. I dont have this card in production, but in > my test environment it was much more stable on RELENG_8 with the above patch > in that I was not able to wedge the box. pps rates were pretty ok on a low > end i7 as well. Thanks for the information. I'll give it a try. I have a problem when I flood a system with SCTP INITs. The system under attack becomes completely unresponsive on the console. However, it continues to send INIT-ACKs back. After the last commit from Jack it recovers after the attack. Not yet sure what is going on. Using the em driver does not have the problem. However, when using the em driver only one core is fully used, when using the igb driver both cores are fully used. Unfortunately I do not have a more than dual core machine available for this testing... Best regards Michael > >---Mike > > > > Mike Tancsa, tel +1 519 651 3400 > Sentex Communications,m...@sentex.net > Providing Internet since 1994www.sentex.net > Cambridge, Ontario Canada www.sentex.net/mike > > ___ 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: igb interrupt moderation
On Jan 3, 2010, at 6:00 PM, Barney Cordoba wrote: > > > --- On Sun, 1/3/10, Michael Tüxen wrote: > >> From: Michael Tüxen >> Subject: Re: igb interrupt moderation >> To: "Mike Tancsa" >> Cc: "Barney Cordoba" , jfvo...@gmail.com, >> freebsd-net@freebsd.org >> Date: Sunday, January 3, 2010, 11:38 AM >> On Jan 3, 2010, at 5:23 PM, Mike >> Tancsa wrote: >> >>> At 11:13 AM 1/3/2010, Michael Tüxen wrote: >>>>> >>>>> Just a separate datapoint about this driver, >> unless I apply >>>>> >>>>> http://people.freebsd.org/~yongari/igb/igb.buf.patch6 >>>>> >>>>> the driver is not really usable for me in >> RELENG_8 on the dual port version of the card >>>> Could you elaborate on what you mean by "not >> really usable"? >>> >>> >>> Hi, >>> Some link state issues >> (getting confused about what port is up), problems at high >> packet rates. I dont have this card in production, but >> in my test environment it was much more stable on RELENG_8 >> with the above patch in that I was not able to wedge the >> box. pps rates were pretty ok on a low end i7 as >> well. >> Thanks for the information. I'll give it a try. I have a >> problem when I flood >> a system with SCTP INITs. The system under attack becomes >> completely unresponsive >> on the console. However, it continues to send INIT-ACKs >> back. After the last >> commit from Jack it recovers after the attack. Not yet sure >> what is going on. >> Using the em driver does not have the problem. However, >> when using the em >> driver only one core is fully used, when using the igb >> driver both cores are fully >> used. Unfortunately I do not have a more than dual core >> machine available for >> this testing... > > Try em and lower the interrupt moderation to something like 500 (about > 100 packets per int is good). The latency isn't going to be noticable and > you'll see your cpu burden reduced quite a bit. I'll try. Thanks. > > Are you using a single NIC on a server, or do you have a firewall or > bridge? The system is a sender/receiver for SCTP. I'm interested in the 82576 since it provides checksum offloading for it. I use one or two ports for simultaneous data transfer. The cards using the em driver do not support this feature. So I'm trying to verify that the performance goes up when using hardware checksum. But under attack, this is currently not the case... > > Barney > > > > > > ___ 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: igb interrupt moderation
On Jan 3, 2010, at 6:35 PM, Barney Cordoba wrote: > --- On Sun, 1/3/10, Michael Tüxen wrote: > >> From: Michael Tüxen >> Subject: Re: igb interrupt moderation >> To: "Barney Cordoba" >> Cc: freebsd-net@freebsd.org, "Mike Tancsa" >> Date: Sunday, January 3, 2010, 12:14 PM >> On Jan 3, 2010, at 6:00 PM, Barney >> Cordoba wrote: >> >>> >>> >>> --- On Sun, 1/3/10, Michael Tüxen >> wrote: >>> >>>> From: Michael Tüxen >>>> Subject: Re: igb interrupt moderation >>>> To: "Mike Tancsa" >>>> Cc: "Barney Cordoba" , >> jfvo...@gmail.com, >> freebsd-net@freebsd.org >>>> Date: Sunday, January 3, 2010, 11:38 AM >>>> On Jan 3, 2010, at 5:23 PM, Mike >>>> Tancsa wrote: >>>> >>>>> At 11:13 AM 1/3/2010, Michael Tüxen wrote: >>>>>>> >>>>>>> Just a separate datapoint about this >> driver, >>>> unless I apply >>>>>>> >>>>>>> http://people.freebsd.org/~yongari/igb/igb.buf.patch6 >>>>>>> >>>>>>> the driver is not really usable for me >> in >>>> RELENG_8 on the dual port version of the card >>>>>> Could you elaborate on what you mean by >> "not >>>> really usable"? >>>>> >>>>> >>>>> Hi, >>>>> Some >> link state issues >>>> (getting confused about what port is up), problems >> at high >>>> packet rates. I dont have this card in >> production, but >>>> in my test environment it was much more stable on >> RELENG_8 >>>> with the above patch in that I was not able to >> wedge the >>>> box. pps rates were pretty ok on a low end >> i7 as >>>> well. >>>> Thanks for the information. I'll give it a try. I >> have a >>>> problem when I flood >>>> a system with SCTP INITs. The system under attack >> becomes >>>> completely unresponsive >>>> on the console. However, it continues to send >> INIT-ACKs >>>> back. After the last >>>> commit from Jack it recovers after the attack. Not >> yet sure >>>> what is going on. >>>> Using the em driver does not have the problem. >> However, >>>> when using the em >>>> driver only one core is fully used, when using the >> igb >>>> driver both cores are fully >>>> used. Unfortunately I do not have a more than dual >> core >>>> machine available for >>>> this testing... >>> >>> Try em and lower the interrupt moderation to something >> like 500 (about >>> 100 packets per int is good). The latency isn't going >> to be noticable and >>> you'll see your cpu burden reduced quite a bit. >> I'll try. Thanks. >>> >>> Are you using a single NIC on a server, or do you have >> a firewall or >>> bridge? >> The system is a sender/receiver for SCTP. I'm interested in >> the 82576 >> since it provides checksum offloading for it. I use one or >> two ports >> for simultaneous data transfer. The cards using the em >> driver do >> not support this feature. So I'm trying to verify that the >> performance >> goes up when using hardware checksum. But under attack, >> this is currently >> not the case... >>> >>> Barney > > I usually try to find something that actually works before I worry > about special features. But we all work differently. ... I want to make sure that the SCTP stuff works. So others can "just use it". SCTP checksum offloading is one important feature... > > Barney > > > > ___ 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: Wireshark, netperf and sctp problem
Hi Frank, you might want to send both wireshark trace to me and I would have a look. If it is a bulk transfer, maybe the Ubuntu machine did not capture all packets. The number of dropped packets is displayed when you stop capturing. Best regards Michael On Feb 18, 2010, at 3:35 PM, frank.schuste...@web.de wrote: > Hello, > > I have a problem with my little network test. > I want to test sctp between ubuntu and freebsd. > On ubuntu I wrote a iptables rule which delete every tenth (10) data package. > Freebsd has no firewall rules. > But only ubuntu sends data and freebsd only acknowledge this data (i did the > test with netperf). > > On the sending side (ubuntu) I see in wireshark 24 data packages, and on the > receiving side (freebsd) I saw 82 packages. > But I can't explain, why freebsd receives more packages as delivered from > ubuntu? (I have currently only one freebsd system). > > Any ideas or something additional notes to help me? > > Is the problem by wireshark or the kernel implementation? > > Regards > Frank > __ > GRATIS für alle WEB.DE-Nutzer: Die maxdome Movie-FLAT! > Jetzt freischalten unter http://movieflat.web.de > > ___ > 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: Kernel Panic in SCTP
Hi Joe, are you able to provide enough information such that I can reproduce this problem? Best regards Michael On Aug 22, 2008, at 4:20 PM, Joseph Mays wrote: Hello. We've recently written an extensive software system that uses SCTP as a critical component. We've started to run into an issue where the box kenel panics after throwing an error message from sctp_timer.c that says "Our list is out of order? Out of order list". Can anyone here shed light on what's going on, or give us a clue how to debug this? http://fxr.watson.org/fxr/source/netinet/sctp_timer.c#L645 Joe Mays ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]" ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
