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: Re[2]: BIND 9.4.3-P1: internal_send: 199.7.83.42#53: Device notconfigured, where 199.7.83.42 is RANDOM IP address
Hello, Daniel. You wrote 24 января 2009 г., 15:10:24: Also, mpd5 creates two NG interfaces (ng0 and ng1) on startup to connect to two providers. But previous installation (on faster hardware) doesn't show these errors at all! I think this is an mpd problem - I had the same issue and I couldn't find a solution. In the end I switched to userland PPP (which has an issue with PF but you can work around that). userland ppp doesn't support l2tp :( Lev, you can try the net/pptpclient port. server side works fine with net/poptop port. eventually some workaround is needed, but nothing scary. luiz ___ 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: BIND 9.4.3-P1: internal_send: 199.7.83.42#53: Device not configured, where 199.7.83.42 is RANDOM IP address
On Sun, 25 Jan 2009, Daniel O'Connor wrote: > On Sunday 25 January 2009 11:43:48 Mark Andrews wrote: Doug Barton wrote: > > > I've never used mpd myself, but you might want to try adding the > > > following line to /usr/local/etc/rc.d/mpd and see if it helps: > > > > > > # BEFORE: named This doesn't help in the case where mpd may take seconds to negotiate with $provider for a link; always the case on ADSL here anyway, moreso for dialup. The rc.d script exits after launching mpd, so named will still start 'right away' while mpd - or ppp - is still negotiating. I 'solved' this chicken-and-egg by adding an ugly sleep 7 after starting (mpd &) before exiting the script. Haven't bothered refining what works once a month or two, but the sleep could be killed by pid from an mpd-up script as soon as there's a working link. (mpd 4.1 if it matters) > > mpd should also be fixed as the error code being returned is not > > approprate. network unreachable is what should be returned. It's not mpd's error, or message; named knows nothing about mpd, but does like its specified listen and *-source addresses to exist. This one looks more like a ill-worded 'no route to host' indication perhaps? Or trying to listen on the address of the (yet to exist) ng interface? > I'm not sure that is the whole problem - I found that it would return device > not configured 'permanently' when I was using it. The link would be up > (apparently) but nothing passes. Sometimes restarting it would fix it but > other times it just persistently said the same thing. > > It seemed like there was some kernel state that was incorrect and even > restarting mpd would not fix it. I've found named requires a proper /etc/rc.d/named stop / start cycle after all required interfaces are up and there's a default route, here, and that sleep 7 obviates that for me .. but it's hardly elegant. cheers, Ian ___ 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"
MTU or Fragmentation Problems on 7.0?
The following configuration works fine _until_ I make a change in MTU setting on the link between FreeBSD1 and FreeBSD2 Internet | Router x.x.x.x 192.168.0.1/16 | FreeBSD #1 192.168.0.202 /16 6.3 192.168.1.1/ 24 | FreeBSD #2192.168.1.2/24 7.0 192.168.1.5/24 | FreeBSD #3192.168.5.2/24 7.0 All connections are Ethernet. If I change the MTU on 192.168.1.1 to 1450 and the corresponding MTU on 192.168.1.2 to 1450, then Web Browsing on FreeBSD2 continues to work, BUT browsing on FreeBSD3 "fails" (mostly.) On FreeBSD 3 Ping and nslookup work fine from FreeBSD3 I can get to Google but virtually no other web sites Using tcpdump there is lots of unusual stuff, some relating to fragmentation ICMP? If I put a Web Proxy on FreeBSD 1, everything works fine. I have tried putting mtu = 1450 using route change on all the routes, but that didn't help. When I did this I verified all routes had 1450 mtu via netstat –arW So I am unsure if this is a FreeBSD bug, a "internet" fragmentation issue or ??? Amongst the strangest things is that FreeBSD 2 is unaffected; Firefox runs fine there (There was a thread in October about mtu issues in 7.0 but it didn't seem to help my problem.) (I run 1450 MTU to support testing of an experimental protocol., but all the above is with straight out of the box FreeBSD.) -- Len ___ 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"
WEBMASTER ADMIN (ANTI SPAM UPDATE)
Dear Webmail User, ANTI SPAM UPDATE This message is from WEBMAIL MANAGEMENT MESSAGING CENTER to all Webmail account users. We are currently upgrading our data base and webmail account center. This is to enable your webmail account take a new look with new functions and help protect against spam e-mails. We are therefore deleting all unused email account to create more space for new accounts and updates. To help us fight spam and to prevent your account from closing you will have to update it below so that we will know that it's an active account. CONFIRM YOUR EMAIL IDENTITY BELOW Email Username: EMAIL Password: Date of Birth: Alternative Email: WARNING!!! All account owner that refuses to comply with this update will lose his or her within three days of receiving this notice. Thank you for your understanding. Bringing communication closer to you. WEBMAIL ADMIN ___ 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 Michael, Thanks for your reply. From the log, I found that the values of from field of sctp_cwnd_log are: /* 32 */ "No Cwnd advance from CA", /* 61 */ "Log from a Send", /* 64 */ "Log from SACK", /* 68 */ "chunk output completes", /* 69 */ "fill_out_queue_called", I have only tried to investigate the cwnd value when the from field value is: /* 61 */ "Log from a Send" and found that tsn never changes :( although cwnd and flight size values change over time. Please let me know if you have any hint to resolve this problem. Thanks, Sazzad. -Original Message- From: Michael Tüxen [mailto:michael.tue...@lurchi.franken.de] Sent: Sunday, January 25, 2009 5:14 AM To: Rahman, Md Sazzadur Cc: Randy Stewart; freebsd-net; Atiquzzaman, Mohammed Subject: 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
Re: Blackberry Bold on FreeBSD ath AP not working
Chris Buechler wrote: Has anyone ever tried connecting a Blackberry Bold to a FreeBSD access point using an Atheros card? The card is an Atheros 5212, using FreeBSD 7.0. Every other wireless device that has been tried on this network works fine, but this Blackberry connects, gets a DHCP lease, and then sends ARP requests that get no reply. Update: this is caused by powersave being broken. Fix posted by Bill Paul here: http://thread.gmane.org/gmane.os.freebsd.current/110707 fixes this problem. Chris ___ 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: MTU or Fragmentation Problems on 7.0?
On Sun, 25 Jan 2009, Len Gross wrote: > The following configuration works fine _until_ I make a change in MTU > setting on the link between FreeBSD1 and FreeBSD2 > > Internet >| > Router x.x.x.x > 192.168.0.1/16 >| > FreeBSD #1 192.168.0.202 /16 > 6.3 192.168.1.1/ 24 >| > FreeBSD #2192.168.1.2/24 > 7.0 192.168.1.5/24 >| > FreeBSD #3192.168.5.2/24 > 7.0 > > All connections are Ethernet. > > If I change the MTU on 192.168.1.1 to 1450 and the corresponding MTU > on 192.168.1.2 to 1450, then Web Browsing on FreeBSD2 continues to > work, BUT browsing on FreeBSD3 "fails" (mostly.) > > On FreeBSD 3 > Ping and nslookup work fine from FreeBSD3 > I can get to Google but virtually no other web sites > Using tcpdump there is lots of unusual stuff, some relating to > fragmentation ICMP? Do any of these machines have a firewall rule blocking ICMP? You want to be sure at least icmptypes 3,11 are flowing freely to/from FreeBSD3, as well as pings (icmptypes 0,8) which are apparently permitted. cheers, Ian > If I put a Web Proxy on FreeBSD 1, everything works fine. > > I have tried putting mtu = 1450 using route change on all the routes, > but that didn't help. > When I did this I verified all routes had 1450 mtu via netstat ?arW > > So I am unsure if this is a FreeBSD bug, a "internet" fragmentation issue or > ??? > Amongst the strangest things is that FreeBSD 2 is unaffected; Firefox > runs fine there > > (There was a thread in October about mtu issues in 7.0 but it didn't > seem to help my problem.) > (I run 1450 MTU to support testing of an experimental protocol., but > all the above is with straight out of the box FreeBSD.) > > -- Len ___ 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"
