Re: IPPROTO_DIVERT and PF_INET6
Bruce M. Simpson wrote: Julian Elischer wrote: you could implement a whole new protocol family of which there was a single protocol.. divert. That's sheer overkill for what Edwin needs to be able to do. We already have a bunch of apps which use divert sockets in the IPv4 space, why should the existing semantics change? Divert sockets are still tied to the transport you instantiate them with, and they have always been a special case anyway depending on where one wishes to draw the lines. There is no reason per se, that I can see, why the IPPROTO_DIVERT identifier can't just be re-used along with pf_proto_register() for PF_INET6, and I've said this to Edwin off-list. A PROTO_SPACER entry just needs to be added to in6protosw. I was surprised to learn no-one had gone ahead and actually implemented it already as there are a few cases in IPv6 which might warrant it (6to4, Teredo etc.) If I'm missing anything obvious please let me know. cheers BMS actually the divert sockets should really not be in PF_INET they could deliver both inet and inet6 packets. the sockaddr that they return (and which needs to be read for divert to make sense) could be used to distinguish between them. ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Problems with netgraph
David DeSimone wrote: Julian Elischer [EMAIL PROTECTED] wrote: unfortunatly I've been totally ignoring this thread because it said trouble with em in the topic.. If you'd said trouble with mpd then maybe I'd have looked earlier.. In the poster's defense, the only symptom that started this was this info from ps: PID USERNAME THR PRI NICE SIZERES STATE C TIME WCPU COMMAND 29 root1 -68- 0K16K CPU5 5 196:41 100.00% em0 taskq So tracking it down to mpd has been a process of elimination in figuring out why packets absorb so much CPU. Here is a result of profiling: http://lists.freebsd.org/pipermail/freebsd-net/2008-May/017901.html -- Oleksandr Samoylyk OVS-RIPE ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to [EMAIL PROTECTED]
Fwd: [networking-discuss] uperf - A network benchmark tool
FYI - Forwarded message from Neelakanth Nadgir [EMAIL PROTECTED] - Date: Tue, 06 May 2008 17:34:23 -0700 From: Neelakanth Nadgir [EMAIL PROTECTED] To: [EMAIL PROTECTED] Cc: Neelakanth Nadgir [EMAIL PROTECTED] Subject: [networking-discuss] uperf - A network benchmark tool [apologies if you received duplicates] Folks, we just opensourced (under GPL v3) a network benchmarking tool called uperf at http://www.uperf.org. I encourage you to check it out. uperf (just like filebench) takes a description of the networking component of workloads and replays it. Using a model allows you to change different parameters (like scale, protocol, etc..) and analyze performance. I hope you find it useful. Uperf is work in progress and we are adding more functionality. If you would like to contribute, please feel free so; we can use all the help. thanks, -neel -- --- Neelakanth Nadgir http://blogs.sun.com/realneel ___ networking-discuss mailing list [EMAIL PROTECTED] - End forwarded message - IMPORTANT: This email remains the property of the Australian Defence Organisation and is subject to the jurisdiction of section 70 of the CRIMES ACT 1914. If you have received this email in error, you are requested to contact the sender and delete the email. ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: IPPROTO_DIVERT and PF_INET6
Julian Elischer wrote: actually the divert sockets should really not be in PF_INET they could deliver both inet and inet6 packets. the sockaddr that they return (and which needs to be read for divert to make sense) could be used to distinguish between them. Good point. I'd forgotten that they were abusing the fields in sin_zero. This is not OK for IPv6, although the kludge can still be perpetuated by looking at sa_len and stashing what divert wants at the end of sockaddr_in6. So there IS a case for making them a separate protocol family if someone's going to do a clean implementation of divert sockets for IPv6. cheers BMS ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: multiple routing tables review patch ready for simple testing.
On Tue, 6 May 2008, Julian Elischer wrote: Hi, Bjoern A. Zeeb wrote: On Tue, 29 Apr 2008, Julian Elischer wrote: Hi, The patch can be found at http://www.freebsd.org/~julian/mrt.diff (or http://www.freebsd.org/~julian/mrt6.diff for RELENG_6) or source can be taken from perforce at: //depot/user/julian/routing/src So after looking at the patch a bit more again, could you add wrapper functions for those like you have done for the old KPI (rtrequest, rtrequest1, do you really want to do the extra work instructions? ... The defines will not give you a stable KPI and having that changed again if you are going with a prefix for each AF would be a pain if the _fib versions are going to change in the future. hmm fair enough... but let me outline my plans and thoughts so we can see if you still want this.. [ ... ] This all however is not ABI compatible so could not go back to 7.x and I want to check in an initial version that can go back to 7.x which sort of suggests to me that adding in_xxx functions is not really required, until I do the next step. 7.x will never get the next step. because the ABI is already set in stone for 7.x. I would make the in_xxx stubs in the next step in 8.x. after the MFC to 7.x of the ABI compat version. let me know what you think. Leaving aside any upcoming enhancement if what we have now is what is going into 7 and possibly 6 we should do the wrapper functions. The point is RELENG_7 will live for $(last release + 2 years) so I guess till 2011 or maybe later. No idea what would happen there in all that time. If people start adding support for other AFs we cannot say that the *_fib variants are not going to change so having the in_* stable sounds like a good thing for 6 and 7. Am I missing anything obvious? I don't mind if they are going to significantly change again in 8 a few weeks later. /bz -- Bjoern A. Zeeb Stop bit received. Insert coin for new game. ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Problems with netgraph
Oleksandr Samoylyk wrote: David DeSimone wrote: Julian Elischer [EMAIL PROTECTED] wrote: unfortunatly I've been totally ignoring this thread because it said trouble with em in the topic.. If you'd said trouble with mpd then maybe I'd have looked earlier.. In the poster's defense, the only symptom that started this was this info from ps: PID USERNAME THR PRI NICE SIZERES STATE C TIME WCPU COMMAND 29 root1 -68- 0K16K CPU5 5 196:41 100.00% em0 taskq So tracking it down to mpd has been a process of elimination in figuring out why packets absorb so much CPU. Here is a result of profiling: http://lists.freebsd.org/pipermail/freebsd-net/2008-May/017901.html 0.000.00 16/1643247 igmp_input [833] 0.030.01 614/1643247 icmp_input [272] 93.07 17.27 1642617/1643247 encap4_input [9] [10]49.8 93.10 17.27 1643247 rip_input [10] 14.260.88 600796/749987 _mtx_lock_sleep [21] 0.161.70 1643863/1643863 raw_append [93] 0.000.24 36345/176995 _mtx_unlock_sleep [114] 0.010.00 1643863/5117962 jailed [278] 0.000.001292/1843m_copym [666] 0.000.00 676/8214484 m_freem [34] 50% of time in rip_input??? that's unexpected.. what is the traffic? also: I see no netgraph in the profile at all. did you statically compile it all in at compile time? (you should if you want to see it) ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: IPPROTO_DIVERT and PF_INET6
Bruce M. Simpson wrote: Julian Elischer wrote: actually the divert sockets should really not be in PF_INET they could deliver both inet and inet6 packets. the sockaddr that they return (and which needs to be read for divert to make sense) could be used to distinguish between them. Good point. I'd forgotten that they were abusing the fields in sin_zero. they == me :-) if we made it its own protocol family we could define our own sockaddr types too and have actual fields for that stuff... This is not OK for IPv6, although the kludge can still be perpetuated by looking at sa_len and stashing what divert wants at the end of sockaddr_in6. So there IS a case for making them a separate protocol family if someone's going to do a clean implementation of divert sockets for IPv6. cheers BMS ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Problems with netgraph
Julian Elischer wrote: Oleksandr Samoylyk wrote: David DeSimone wrote: Julian Elischer [EMAIL PROTECTED] wrote: unfortunatly I've been totally ignoring this thread because it said trouble with em in the topic.. If you'd said trouble with mpd then maybe I'd have looked earlier.. In the poster's defense, the only symptom that started this was this info from ps: PID USERNAME THR PRI NICE SIZERES STATE C TIME WCPU COMMAND 29 root1 -68- 0K16K CPU5 5 196:41 100.00% em0 taskq So tracking it down to mpd has been a process of elimination in figuring out why packets absorb so much CPU. Here is a result of profiling: http://lists.freebsd.org/pipermail/freebsd-net/2008-May/017901.html 0.000.00 16/1643247 igmp_input [833] 0.030.01 614/1643247 icmp_input [272] 93.07 17.27 1642617/1643247 encap4_input [9] [10]49.8 93.10 17.27 1643247 rip_input [10] 14.260.88 600796/749987 _mtx_lock_sleep [21] 0.161.70 1643863/1643863 raw_append [93] 0.000.24 36345/176995 _mtx_unlock_sleep [114] 0.010.00 1643863/5117962 jailed [278] 0.000.001292/1843m_copym [666] 0.000.00 676/8214484 m_freem [34] 50% of time in rip_input??? that's unexpected.. what is the traffic? more than 20k pps # netstat -I em0 -w 1 input (em0) output packets errs bytespackets errs bytes colls 22247 0 10767499 21079 0 13741924 0 21356 0 10535580 20288 0 13014669 0 21871 0 10565622 20586 0 13165147 0 21894 0 10495771 20964 0 13806336 0 21303 0 10496544 19682 0 12659588 0 21643 0 10561207 20140 0 12692946 0 21534 0 10304466 20289 0 13460444 0 ^C also: I see no netgraph in the profile at all. did you statically compile it all in at compile time? (you should if you want to see it) Tried both variants. Now not statically. -- Oleksandr Samoylyk OVS-RIPE ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Problems with netgraph
Oleksandr Samoylyk wrote: Julian Elischer wrote: Oleksandr Samoylyk wrote: David DeSimone wrote: Julian Elischer [EMAIL PROTECTED] wrote: unfortunatly I've been totally ignoring this thread because it said trouble with em in the topic.. If you'd said trouble with mpd then maybe I'd have looked earlier.. In the poster's defense, the only symptom that started this was this info from ps: PID USERNAME THR PRI NICE SIZERES STATE C TIME WCPU COMMAND 29 root1 -68- 0K16K CPU5 5 196:41 100.00% em0 taskq So tracking it down to mpd has been a process of elimination in figuring out why packets absorb so much CPU. Here is a result of profiling: http://lists.freebsd.org/pipermail/freebsd-net/2008-May/017901.html 0.000.00 16/1643247 igmp_input [833] 0.030.01 614/1643247 icmp_input [272] 93.07 17.27 1642617/1643247 encap4_input [9] [10]49.8 93.10 17.27 1643247 rip_input [10] 14.260.88 600796/749987 _mtx_lock_sleep [21] 0.161.70 1643863/1643863 raw_append [93] 0.000.24 36345/176995 _mtx_unlock_sleep [114] 0.010.00 1643863/5117962 jailed [278] 0.000.001292/1843m_copym [666] 0.000.00 676/8214484 m_freem [34] 50% of time in rip_input??? that's unexpected.. what is the traffic? more than 20k pps I mean, what KIND of traffic? I'm surprised it 's calling rip_input().. why is it calling encap4_input()? (which calls rip_input).. what is the IP protocol of all these packets? what does a small snippet of traffic show? (tcpdump -i em0 -s0 -e -n -c 64) I see no netgraph in the profile at all. did you statically compile it all in at compile time? (you should if you want to see it) Tried both variants. Now not statically. make sure it is static and that the netgraph nodes are all compiled with -pg ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Problems with netgraph
Julian Elischer wrote:
Oleksandr Samoylyk wrote:
Julian Elischer wrote:
Oleksandr Samoylyk wrote:
David DeSimone wrote:
Julian Elischer [EMAIL PROTECTED] wrote:
unfortunatly I've been totally ignoring this thread because it said
trouble with em in the topic..
If you'd said trouble with mpd then maybe I'd have looked earlier..
In the poster's defense, the only symptom that started this was this
info from ps:
PID USERNAME THR PRI NICE SIZERES STATE C TIME WCPU
COMMAND
29 root1 -68- 0K16K CPU5 5 196:41 100.00%
em0 taskq
So tracking it down to mpd has been a process of elimination in
figuring
out why packets absorb so much CPU.
Here is a result of profiling:
http://lists.freebsd.org/pipermail/freebsd-net/2008-May/017901.html
0.000.00 16/1643247 igmp_input [833]
0.030.01 614/1643247 icmp_input [272]
93.07 17.27 1642617/1643247 encap4_input [9]
[10]49.8 93.10 17.27 1643247 rip_input [10]
14.260.88 600796/749987 _mtx_lock_sleep
[21]
0.161.70 1643863/1643863 raw_append [93]
0.000.24 36345/176995 _mtx_unlock_sleep
[114]
0.010.00 1643863/5117962 jailed [278]
0.000.001292/1843m_copym [666]
0.000.00 676/8214484 m_freem [34]
50% of time in rip_input???
that's unexpected.. what is the traffic?
more than 20k pps
I mean, what KIND of traffic?
I'm surprised it 's calling rip_input().. why is it calling
encap4_input()? (which calls rip_input).. what is the IP protocol
of all these packets?
what does a small snippet of traffic show?
(tcpdump -i em0 -s0 -e -n -c 64)
GRE (pptp-tunnels)
tcpdump -i em0 -s0 -e -n -c 64
22:43:28.818558 00:19:d1:03:ce:7e 00:12:cf:53:61:30, ethertype IPv4
(0x0800), length 250: 10.0.0.8.22 10.0.14.191.3513: P
3482978131:3482978327(196) ack 537019550 win 128
22:43:28.818892 00:19:d1:03:ce:7e 00:12:cf:53:61:30, ethertype IPv4
(0x0800), length 1447: 10.0.0.8 10.0.113.178: GREv1, call 256, seq
949074, proto PPP (0x880b), length 1413: IP (0x0021), length 1401:
89.252.42.44.40002 77.120.207.229.3038: . 588169704:588171064(1360)
ack 239105401 win 58593
22:43:28.819014 00:19:d1:03:ce:7e 00:12:cf:53:61:30, ethertype IPv4
(0x0800), length 1447: 10.0.0.8 10.0.34.188: GREv1, call 0, seq
28109460, proto PPP (0x880b), length 1413: IP (0x0021), length 1401:
195.91.147.100.62073 77.120.205.18.43463: .
2979675127:2979676487(1360) ack 3166103641 win 65212
22:43:28.819016 00:11:92:c5:a7:40 00:19:d1:03:ce:7e, ethertype IPv4
(0x0800), length 111: 10.0.197.49 10.0.0.8: GREv1, call 39317, seq
1841830, ack 2346966, proto PPP (0x880b), length 77: IP (0x0021), length
61: 77.120.205.65.1109 89.254.129.137.63441: . ack 2160932834 win
17680 nop,nop,sack 2 {6801:8161}{4081:5441}
22:43:28.819025 00:19:d1:03:ce:7e 00:12:cf:53:61:30, ethertype IPv4
(0x0800), length 1447: 10.0.0.8 10.0.113.178: GREv1, call 256, seq
949075, proto PPP (0x880b), length 1413: IP (0x0021), length 1401:
89.252.42.44.40002 77.120.207.229.3038: . 1360:2720(1360) ack 1 win 58593
22:43:28.819109 00:19:d1:03:ce:7e 00:12:cf:53:61:30, ethertype IPv4
(0x0800), length 46: 10.0.0.8 10.0.197.49: GREv1, call 16384, ack
1841830, no-payload, proto PPP (0x880b), length 12
22:43:28.819152 00:19:d1:03:ce:7e 00:12:cf:53:61:30, ethertype IPv4
(0x0800), length 1447: 10.0.0.8 10.0.7.198: GREv1, call 32768, seq
2854449, proto PPP (0x880b), length 1413: IP (0x0021), length 1401:
88.81.240.172.80 77.120.206.140.3573: . 2985100912:2985102272(1360)
ack 3056545326 win 32254
22:43:28.819259 00:19:d1:03:ce:7e 00:12:cf:53:61:30, ethertype IPv4
(0x0800), length 1447: 10.0.0.8 10.0.34.188: GREv1, call 0, seq
28109461, proto PPP (0x880b), length 1413: IP (0x0021), length 1401:
195.91.147.100.62073 77.120.205.18.43463: . 1360:2720(1360) ack 1 win
65212
22:43:28.819632 00:19:d1:03:ce:7e 00:12:cf:53:61:30, ethertype IPv4
(0x0800), length 87: 10.0.0.8 10.0.3.36: GREv1, call 33358, seq
809410, proto PPP (0x880b), length 53: IP (0x0021), length 41:
89.189.135.94.29934 77.120.205.175.64039: . ack 980726719 win 65535
22:43:28.820102 00:11:92:c5:a7:40 00:19:d1:03:ce:7e, ethertype IPv4
(0x0800), length 91: 10.0.7.198 10.0.0.8: GREv1, call 42872, seq
1687270, ack 2854449, proto PPP (0x880b), length 57: IP (0x0021), length
41: 77.120.206.140.3573 88.81.240.172.80: . ack 1360 win 65535
22:43:28.820172 00:19:d1:03:ce:7e 00:12:cf:53:61:30, ethertype IPv4
(0x0800), length 46: 10.0.0.8 10.0.7.198: GREv1, call 32768, ack
1687270, no-payload, proto PPP (0x880b), length 12
22:43:28.820255 00:19:d1:03:ce:7e 00:12:cf:53:61:30, ethertype IPv4
(0x0800), length 461: 10.0.0.8 10.0.7.198: GREv1, call 32768, seq
2854450, proto PPP (0x880b), length 427: IP (0x0021),
Re: Problems with netgraph
Oleksandr Samoylyk wrote:
Julian Elischer wrote:
Oleksandr Samoylyk wrote:
Julian Elischer wrote:
Oleksandr Samoylyk wrote:
David DeSimone wrote:
Julian Elischer [EMAIL PROTECTED] wrote:
unfortunatly I've been totally ignoring this thread because it said
trouble with em in the topic..
If you'd said trouble with mpd then maybe I'd have looked
earlier..
In the poster's defense, the only symptom that started this was this
info from ps:
PID USERNAME THR PRI NICE SIZERES STATE C TIME WCPU
COMMAND
29 root1 -68- 0K16K CPU5 5 196:41 100.00%
em0 taskq
So tracking it down to mpd has been a process of elimination in
figuring
out why packets absorb so much CPU.
Here is a result of profiling:
http://lists.freebsd.org/pipermail/freebsd-net/2008-May/017901.html
0.000.00 16/1643247 igmp_input [833]
0.030.01 614/1643247 icmp_input [272]
93.07 17.27 1642617/1643247 encap4_input [9]
[10]49.8 93.10 17.27 1643247 rip_input [10]
14.260.88 600796/749987
_mtx_lock_sleep [21]
0.161.70 1643863/1643863 raw_append [93]
0.000.24 36345/176995 _mtx_unlock_sleep
[114]
0.010.00 1643863/5117962 jailed [278]
0.000.001292/1843m_copym [666]
0.000.00 676/8214484 m_freem [34]
50% of time in rip_input???
that's unexpected.. what is the traffic?
more than 20k pps
I mean, what KIND of traffic?
I'm surprised it 's calling rip_input().. why is it calling
encap4_input()? (which calls rip_input).. what is the IP protocol
of all these packets?
what does a small snippet of traffic show?
(tcpdump -i em0 -s0 -e -n -c 64)
GRE (pptp-tunnels)
tcpdump -i em0 -s0 -e -n -c 64
22:43:28.818558 00:19:d1:03:ce:7e 00:12:cf:53:61:30, ethertype IPv4
(0x0800), length 250: 10.0.0.8.22 10.0.14.191.3513: P
3482978131:3482978327(196) ack 537019550 win 128
22:43:28.818892 00:19:d1:03:ce:7e 00:12:cf:53:61:30, ethertype IPv4
(0x0800), length 1447: 10.0.0.8 10.0.113.178: GREv1, call 256, seq
949074, proto PPP (0x880b), length 1413: IP (0x0021), length 1401:
89.252.42.44.40002 77.120.207.229.3038: . 588169704:588171064(1360)
ack 239105401 win 58593
22:43:28.819014 00:19:d1:03:ce:7e 00:12:cf:53:61:30, ethertype IPv4
(0x0800), length 1447: 10.0.0.8 10.0.34.188: GREv1, call 0, seq
28109460, proto PPP (0x880b), length 1413: IP (0x0021), length 1401:
195.91.147.100.62073 77.120.205.18.43463: .
2979675127:2979676487(1360) ack 3166103641 win 65212
22:43:28.819016 00:11:92:c5:a7:40 00:19:d1:03:ce:7e, ethertype IPv4
(0x0800), length 111: 10.0.197.49 10.0.0.8: GREv1, call 39317, seq
1841830, ack 2346966, proto PPP (0x880b), length 77: IP (0x0021), length
61: 77.120.205.65.1109 89.254.129.137.63441: . ack 2160932834 win
17680 nop,nop,sack 2 {6801:8161}{4081:5441}
22:43:28.819025 00:19:d1:03:ce:7e 00:12:cf:53:61:30, ethertype IPv4
(0x0800), length 1447: 10.0.0.8 10.0.113.178: GREv1, call 256, seq
949075, proto PPP (0x880b), length 1413: IP (0x0021), length 1401:
89.252.42.44.40002 77.120.207.229.3038: . 1360:2720(1360) ack 1 win 58593
22:43:28.819109 00:19:d1:03:ce:7e 00:12:cf:53:61:30, ethertype IPv4
(0x0800), length 46: 10.0.0.8 10.0.197.49: GREv1, call 16384, ack
1841830, no-payload, proto PPP (0x880b), length 12
22:43:28.819152 00:19:d1:03:ce:7e 00:12:cf:53:61:30, ethertype IPv4
(0x0800), length 1447: 10.0.0.8 10.0.7.198: GREv1, call 32768, seq
2854449, proto PPP (0x880b), length 1413: IP (0x0021), length 1401:
88.81.240.172.80 77.120.206.140.3573: . 2985100912:2985102272(1360)
ack 3056545326 win 32254
22:43:28.819259 00:19:d1:03:ce:7e 00:12:cf:53:61:30, ethertype IPv4
(0x0800), length 1447: 10.0.0.8 10.0.34.188: GREv1, call 0, seq
28109461, proto PPP (0x880b), length 1413: IP (0x0021), length 1401:
195.91.147.100.62073 77.120.205.18.43463: . 1360:2720(1360) ack 1 win
65212
22:43:28.819632 00:19:d1:03:ce:7e 00:12:cf:53:61:30, ethertype IPv4
(0x0800), length 87: 10.0.0.8 10.0.3.36: GREv1, call 33358, seq
809410, proto PPP (0x880b), length 53: IP (0x0021), length 41:
89.189.135.94.29934 77.120.205.175.64039: . ack 980726719 win 65535
22:43:28.820102 00:11:92:c5:a7:40 00:19:d1:03:ce:7e, ethertype IPv4
(0x0800), length 91: 10.0.7.198 10.0.0.8: GREv1, call 42872, seq
1687270, ack 2854449, proto PPP (0x880b), length 57: IP (0x0021), length
41: 77.120.206.140.3573 88.81.240.172.80: . ack 1360 win 65535
22:43:28.820172 00:19:d1:03:ce:7e 00:12:cf:53:61:30, ethertype IPv4
(0x0800), length 46: 10.0.0.8 10.0.7.198: GREv1, call 32768, ack
1687270, no-payload, proto PPP (0x880b), length 12
22:43:28.820255 00:19:d1:03:ce:7e 00:12:cf:53:61:30, ethertype IPv4
(0x0800), length 461: 10.0.0.8 10.0.7.198: GREv1, call 32768, seq
2854450, proto PPP (0x880b),
Routing problem with aliases
Hello. A box of mine has an interface configured with two IPs on two different nets: # ifconfig xl0: flags=8943UP,BROADCAST,RUNNING,PROMISC,SIMPLEX,MULTICAST mtu 1500 options=9RXCSUM,VLAN_MTU inet 192.168.2.2 netmask 0xff00 broadcast 192.168.2.255 inet 192.168.0.2 netmask 0xff00 broadcast 192.168.0.255 ether 00:50:da:77:5f:79 media: Ethernet autoselect (100baseTX full-duplex) status: active Then I have two gateways: 192.168.2.1 and 192.168.0.6. ping 192.168.2.1 works correctly (source address 192.168.2.2 is used) ping 192.168.0.6 also does (source address 192.168.0.2 is used) Setting 192.168.2.1 as my default gateway allows me to ping any host on the Internet (again source address 192.168.2.2 is used). However, if I set 192.168.0.6 as the default router, I can't reach the Internet, since it uses source address 192.168.2.2 and the next router won't obviously like it. Is this normal behaviour? Anything to set or check? Any other hint? Perhaps I should mention that I also have some carp devices on that interface, but I'm not sure whether it matters. bye Thanks av. ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: kern/123347: [bge] bge1: watchdog timeout -- linkstate changed to DOWN
Synopsis: [bge] bge1: watchdog timeout -- linkstate changed to DOWN State-Changed-From-To: open-feedback State-Changed-By: vwe State-Changed-When: Wed May 7 20:33:44 UTC 2008 State-Changed-Why: It appears there's no PHY attached but from your dmesg I would expect bge0 to cause trouble. Can you please post output of `pciconf -lv | grep -A 3 bge'? I think the -net maintainers will be able to see the relevant pieces from that output. Responsible-Changed-From-To: freebsd-bugs-freebsd-net Responsible-Changed-By: vwe Responsible-Changed-When: Wed May 7 20:33:44 UTC 2008 Responsible-Changed-Why: Over to maintainer(s). http://www.freebsd.org/cgi/query-pr.cgi?pr=123347 ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: kern/123463: [panic] repeatable crash related to ipsec-tools
Old Synopsis: repeatable crash related to ipsec-tools New Synopsis: [panic] repeatable crash related to ipsec-tools Responsible-Changed-From-To: freebsd-bugs-freebsd-net Responsible-Changed-By: vwe Responsible-Changed-When: Wed May 7 21:00:12 UTC 2008 Responsible-Changed-Why: Over to maintainer(s). http://www.freebsd.org/cgi/query-pr.cgi?pr=123463 ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to [EMAIL PROTECTED]
Fw: kern/123347: [bge] bge1: watchdog timeout -- linkstate changed to DOWN
As a follow-up to my previous output, this is also my custom kernel, just in case: # # GENERIC -- Generic kernel configuration file for FreeBSD/i386 # FreeBSD 6.3-RELEASE # For more information on this file, please read the handbook section on # Kernel Configuration Files: # # http://www.FreeBSD.org/doc/en_US.ISO8859-1/books/handbook/kernelconfig-config.html # # The handbook is also available locally in /usr/share/doc/handbook # if you've installed the doc distribution, otherwise always see the # FreeBSD World Wide Web server (http://www.FreeBSD.org/) for the # latest information. # # An exhaustive list of options and more detailed explanations of the # device lines is also present in the ../../conf/NOTES and NOTES files. # If you are in doubt as to the purpose or necessity of a line, check first # in NOTES. # # $FreeBSD: src/sys/i386/conf/GENERIC,v 1.429.2.14.2.1 2007/12/15 06:32:32 scottl Exp $ machine i386 #cpu I486_CPU #cpu I586_CPU cpu I686_CPU ident GBRT2 # To statically compile in device wiring instead of /boot/device.hints #hints GENERIC.hints # Default places to look for devices. makeoptions DEBUG=-g # Build kernel with gdb(1) debug symbols options SCHED_4BSD # 4BSD scheduler options PREEMPTION # Enable kernel thread preemption options INET # InterNETworking options INET6 # IPv6 communications protocols options FFS # Berkeley Fast Filesystem options SOFTUPDATES # Enable FFS soft updates support options UFS_ACL # Support for access control lists options UFS_DIRHASH # Improve performance on big directories options MD_ROOT # MD is a potential root device #options NFSCLIENT # Network Filesystem Client #options NFSSERVER # Network Filesystem Server #options NFS_ROOT # NFS usable as /, requires NFSCLIENT #options MSDOSFS # MSDOS Filesystem options CD9660 # ISO 9660 Filesystem options PROCFS # Process filesystem (requires PSEUDOFS) options PSEUDOFS # Pseudo-filesystem framework options GEOM_GPT # GUID Partition Tables. options COMPAT_43 # Compatible with BSD 4.3 [KEEP THIS!] options COMPAT_FREEBSD4 # Compatible with FreeBSD4 options COMPAT_FREEBSD5 # Compatible with FreeBSD5 #options SCSI_DELAY=5000 # Delay (in ms) before probing SCSI options KTRACE # ktrace(1) support options SYSVSHM # SYSV-style shared memory options SYSVMSG # SYSV-style message queues options SYSVSEM # SYSV-style semaphores options _KPOSIX_PRIORITY_SCHEDULING # POSIX P1003_1B real-time extensions options KBD_INSTALL_CDEV # install a CDEV entry in /dev options ADAPTIVE_GIANT # Giant mutex is adaptive. #To make an SMP kernel, the next two are required options SMP device apic# I/O APIC #IPFIREWALL options IPFIREWALL #firewall options IPFIREWALL_VERBOSE #enable logging to syslogd(8) options IPFIREWALL_FORWARD #enable transparent proxy support options IPFIREWALL_VERBOSE_LIMIT=10#limit verbosity options IPDIVERT options IPFIREWALL_DEFAULT_TO_ACCEPT#allow everything by default options DUMMYNET options HZ=2000 # Bus support. device eisa device pci # Floppy drives #device fdc # ATA and ATAPI devices device ata device atadisk # ATA disk drives device ataraid # ATA RAID drives device atapicd # ATAPI CDROM drives device atapifd # ATAPI floppy drives #device atapist # ATAPI tape drives options ATA_STATIC_ID # Static device numbering # SCSI Controllers #device ahb # EISA AHA1742 family #device ahc # AHA2940 and onboard AIC7xxx devices #options AHC_REG_PRETTY_PRINT # Print register bitfields in debug # output. Adds ~128k to driver. #device ahd # AHA39320/29320 and onboard AIC79xx devices #options AHD_REG_PRETTY_PRINT # Print register bitfields in debug # output. Adds ~215k to driver. #device amd # AMD 53C974 (Tekram DC-390(T)) #device isp # Qlogic family #device ispfw # Firmware for QLogic HBAs- normally a module #device mpt # LSI-Logic MPT-Fusion #device ncr # NCR/Symbios Logic #device sym # NCR/Symbios Logic (newer chipsets + those of `ncr') #device trm # Tekram DC395U/UW/F DC315U adapters #device adv # Advansys SCSI adapters #device adw # Advansys wide SCSI adapters #device aha # Adaptec 154x SCSI adapters #device aic # Adaptec 15[012]x SCSI adapters, AIC-6[23]60. #device bt # Buslogic/Mylex MultiMaster SCSI adapters #device ncv # NCR 53C500 #device nsp # Workbit Ninja SCSI-3 #device stg # TMC 18C30/18C50 # SCSI peripherals #device scbus # SCSI bus (required for SCSI) #device ch # SCSI media changers #device da # Direct Access (disks) #device sa # Sequential Access (tape etc) #device cd # CD #device pass # Passthrough device (direct SCSI access) #device ses # SCSI Environmental Services (and SAF-TE) # RAID controllers interfaced to the SCSI subsystem #device
Re: kern/123347: [bge] bge1: watchdog timeout -- linkstate changed to DOWN
Sure! Here you are! GBRT2# pciconf -lv | grep -A 3 bge [EMAIL PROTECTED]:1:0: class=0x02 card=0x100410b7 chip=0x164514e4 rev=0x15 hdr=0x00 vendor = 'Broadcom Corporation' device = 'BCM5701 NetXtreme BCM5701 Gigabit Ethernet' class = network -- [EMAIL PROTECTED]:2:0: class=0x02 card=0x100010b7 chip=0x164414e4 rev=0x12 hdr=0x00 vendor = 'Broadcom Corporation' device = 'BCM5751F NetXtreme Gigabit Ethernet Controller' class = network GBRT2# - Original Message - From: [EMAIL PROTECTED] To: [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED]; freebsd-net@FreeBSD.org Sent: Wednesday, May 07, 2008 11:37 PM Subject: Re: kern/123347: [bge] bge1: watchdog timeout -- linkstate changed to DOWN Synopsis: [bge] bge1: watchdog timeout -- linkstate changed to DOWN State-Changed-From-To: open-feedback State-Changed-By: vwe State-Changed-When: Wed May 7 20:33:44 UTC 2008 State-Changed-Why: It appears there's no PHY attached but from your dmesg I would expect bge0 to cause trouble. Can you please post output of `pciconf -lv | grep -A 3 bge'? I think the -net maintainers will be able to see the relevant pieces from that output. Responsible-Changed-From-To: freebsd-bugs-freebsd-net Responsible-Changed-By: vwe Responsible-Changed-When: Wed May 7 20:33:44 UTC 2008 Responsible-Changed-Why: Over to maintainer(s). http://www.freebsd.org/cgi/query-pr.cgi?pr=123347 ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Problems with netgraph
Julian Elischer wrote:
Oleksandr Samoylyk wrote:
Julian Elischer wrote:
Oleksandr Samoylyk wrote:
Julian Elischer wrote:
Oleksandr Samoylyk wrote:
David DeSimone wrote:
Julian Elischer [EMAIL PROTECTED] wrote:
unfortunatly I've been totally ignoring this thread because it
said
trouble with em in the topic..
If you'd said trouble with mpd then maybe I'd have looked
earlier..
In the poster's defense, the only symptom that started this was this
info from ps:
PID USERNAME THR PRI NICE SIZERES STATE C TIME WCPU
COMMAND
29 root1 -68- 0K16K CPU5 5 196:41
100.00% em0 taskq
So tracking it down to mpd has been a process of elimination in
figuring
out why packets absorb so much CPU.
Here is a result of profiling:
http://lists.freebsd.org/pipermail/freebsd-net/2008-May/017901.html
0.000.00 16/1643247 igmp_input [833]
0.030.01 614/1643247 icmp_input [272]
93.07 17.27 1642617/1643247 encap4_input [9]
[10]49.8 93.10 17.27 1643247 rip_input [10]
14.260.88 600796/749987
_mtx_lock_sleep [21]
0.161.70 1643863/1643863 raw_append [93]
0.000.24 36345/176995
_mtx_unlock_sleep
[114]
0.010.00 1643863/5117962 jailed [278]
0.000.001292/1843m_copym [666]
0.000.00 676/8214484 m_freem [34]
50% of time in rip_input???
that's unexpected.. what is the traffic?
more than 20k pps
I mean, what KIND of traffic?
I'm surprised it 's calling rip_input().. why is it calling
encap4_input()? (which calls rip_input).. what is the IP protocol
of all these packets?
what does a small snippet of traffic show?
(tcpdump -i em0 -s0 -e -n -c 64)
GRE (pptp-tunnels)
tcpdump -i em0 -s0 -e -n -c 64
22:43:28.818558 00:19:d1:03:ce:7e 00:12:cf:53:61:30, ethertype IPv4
(0x0800), length 250: 10.0.0.8.22 10.0.14.191.3513: P
3482978131:3482978327(196) ack 537019550 win 128
22:43:28.818892 00:19:d1:03:ce:7e 00:12:cf:53:61:30, ethertype IPv4
(0x0800), length 1447: 10.0.0.8 10.0.113.178: GREv1, call 256, seq
949074, proto PPP (0x880b), length 1413: IP (0x0021), length 1401:
89.252.42.44.40002 77.120.207.229.3038: . 588169704:588171064(1360)
ack 239105401 win 58593
22:43:28.819014 00:19:d1:03:ce:7e 00:12:cf:53:61:30, ethertype IPv4
(0x0800), length 1447: 10.0.0.8 10.0.34.188: GREv1, call 0, seq
28109460, proto PPP (0x880b), length 1413: IP (0x0021), length 1401:
195.91.147.100.62073 77.120.205.18.43463: .
2979675127:2979676487(1360) ack 3166103641 win 65212
22:43:28.819016 00:11:92:c5:a7:40 00:19:d1:03:ce:7e, ethertype IPv4
(0x0800), length 111: 10.0.197.49 10.0.0.8: GREv1, call 39317, seq
1841830, ack 2346966, proto PPP (0x880b), length 77: IP (0x0021),
length 61: 77.120.205.65.1109 89.254.129.137.63441: . ack 2160932834
win 17680 nop,nop,sack 2 {6801:8161}{4081:5441}
22:43:28.819025 00:19:d1:03:ce:7e 00:12:cf:53:61:30, ethertype IPv4
(0x0800), length 1447: 10.0.0.8 10.0.113.178: GREv1, call 256, seq
949075, proto PPP (0x880b), length 1413: IP (0x0021), length 1401:
89.252.42.44.40002 77.120.207.229.3038: . 1360:2720(1360) ack 1 win
58593
22:43:28.819109 00:19:d1:03:ce:7e 00:12:cf:53:61:30, ethertype IPv4
(0x0800), length 46: 10.0.0.8 10.0.197.49: GREv1, call 16384, ack
1841830, no-payload, proto PPP (0x880b), length 12
22:43:28.819152 00:19:d1:03:ce:7e 00:12:cf:53:61:30, ethertype IPv4
(0x0800), length 1447: 10.0.0.8 10.0.7.198: GREv1, call 32768, seq
2854449, proto PPP (0x880b), length 1413: IP (0x0021), length 1401:
88.81.240.172.80 77.120.206.140.3573: . 2985100912:2985102272(1360)
ack 3056545326 win 32254
22:43:28.819259 00:19:d1:03:ce:7e 00:12:cf:53:61:30, ethertype IPv4
(0x0800), length 1447: 10.0.0.8 10.0.34.188: GREv1, call 0, seq
28109461, proto PPP (0x880b), length 1413: IP (0x0021), length 1401:
195.91.147.100.62073 77.120.205.18.43463: . 1360:2720(1360) ack 1
win 65212
22:43:28.819632 00:19:d1:03:ce:7e 00:12:cf:53:61:30, ethertype IPv4
(0x0800), length 87: 10.0.0.8 10.0.3.36: GREv1, call 33358, seq
809410, proto PPP (0x880b), length 53: IP (0x0021), length 41:
89.189.135.94.29934 77.120.205.175.64039: . ack 980726719 win 65535
22:43:28.820102 00:11:92:c5:a7:40 00:19:d1:03:ce:7e, ethertype IPv4
(0x0800), length 91: 10.0.7.198 10.0.0.8: GREv1, call 42872, seq
1687270, ack 2854449, proto PPP (0x880b), length 57: IP (0x0021),
length 41: 77.120.206.140.3573 88.81.240.172.80: . ack 1360 win 65535
22:43:28.820172 00:19:d1:03:ce:7e 00:12:cf:53:61:30, ethertype IPv4
(0x0800), length 46: 10.0.0.8 10.0.7.198: GREv1, call 32768, ack
1687270, no-payload, proto PPP (0x880b), length 12
22:43:28.820255 00:19:d1:03:ce:7e 00:12:cf:53:61:30, ethertype IPv4
(0x0800), length 461: 10.0.0.8 10.0.7.198: GREv1, call 32768, seq
Re: kern/123347: [bge] bge1: watchdog timeout -- linkstate changedto DOWN
Does this really warrant a high priority flag? - Original Message - From: [EMAIL PROTECTED] Sure! Here you are! GBRT2# pciconf -lv | grep -A 3 bge [EMAIL PROTECTED]:1:0: class=0x02 card=0x100410b7 chip=0x164514e4 rev=0x15 hdr=0x00 vendor = 'Broadcom Corporation' device = 'BCM5701 NetXtreme BCM5701 Gigabit Ethernet' class = network ... This e.mail is private and confidential between Multiplay (UK) Ltd. and the person or entity to whom it is addressed. In the event of misdirection, the recipient is prohibited from using, copying, printing or otherwise disseminating it or any information contained in it. In the event of misdirection, illegible or incomplete transmission please telephone +44 845 868 1337 or return the E.mail to [EMAIL PROTECTED] ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: kern/123347: [bge] bge1: watchdog timeout -- linkstate changedto DOWN
I guess it does, since this nightmere is being reported with different NICs and drivers including Intel NICs on em driver and 3Com NICs on bge and xl drivers on 6.3-RELEASE , 6-STABLE, 7.0-RELEAE and 7-STABLE. The mailing list if full of too many questions regarding this issue and no answer! If it realy doesn't worth a high priority flag, then I do appolgize and I shoud fall back to 4.11-RELEASE which worked on the same hardware like a sandwatch! http://www.freebsd.org/cgi/query-pr.cgi?pr=123347 - Original Message - From: Steven Hartland [EMAIL PROTECTED] To: [EMAIL PROTECTED]; [EMAIL PROTECTED] Cc: freebsd-net@FreeBSD.org; [EMAIL PROTECTED] Sent: Thursday, May 08, 2008 12:29 AM Subject: Re: kern/123347: [bge] bge1: watchdog timeout -- linkstate changedto DOWN Does this really warrant a high priority flag? - Original Message - From: [EMAIL PROTECTED] Sure! Here you are! GBRT2# pciconf -lv | grep -A 3 bge [EMAIL PROTECTED]:1:0: class=0x02 card=0x100410b7 chip=0x164514e4 rev=0x15 hdr=0x00 vendor = 'Broadcom Corporation' device = 'BCM5701 NetXtreme BCM5701 Gigabit Ethernet' class = network ... -- [EMAIL PROTECTED]:2:0: class=0x02 card=0x100010b7 chip=0x164414e4 rev=0x12 hdr=0x00 vendor = 'Broadcom Corporation' device = 'BCM5751F NetXtreme Gigabit Ethernet Controller' class = network GBRT2# This e.mail is private and confidential between Multiplay (UK) Ltd. and the person or entity to whom it is addressed. In the event of misdirection, the recipient is prohibited from using, copying, printing or otherwise disseminating it or any information contained in it. In the event of misdirection, illegible or incomplete transmission please telephone +44 845 868 1337 or return the E.mail to [EMAIL PROTECTED] ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: read() returns ETIMEDOUT on steady TCP connection
I've looked at the code paths again. There are two possibilities: a) the mbuf allocator has some anomaly where it rejects memory requests but doesn't update the statistics (the code is there however). b) the error doesn't come from the mbuf allocation but from ip_output() and further down the chain. To differentiate please try this updated patch and report the log output again (don't forget to set net.inet.tcp.log_debug=1): http://people.freebsd.org/~andre/tcp_output-error-log.diff -- Andre Deng XueFeng wrote: hi I'am also meet this problem in my mss server(missey streaming server). one encoder push stream to mss, then run 100 client player playing the sream, as the client number increase, mss will occur this error sooner or later like this: I'am using kqueue, and will got a event with EV_EOF and fflags = ETIMEDOUT, if i ignore EV_EOF flag, then ETIMEDOUT will be return by read(2), and the tcpdump also show that server will send RST packet to encoder. Hello, I'm are having a trouble with TCP connections being dropped with read: Operation timed out. What is unusual is that this is happening right in the middle of sending a steady stream of data with no network congestion. The system is FreeBSD 7 and a bespoke streaming server with 1Gbit connection. The server receives a 192kbps inbound stream over TCP, and broadcasts it over a large number of TCP streams. With no visible or obvious pattern, the inbound read() fails with ETIMEDOUT. The likelihood of this happening seems to increase as the number of audience connections increases. It's happens every few minutes even with a small audience (eg. 300 outbound connections and about 60mbit). It doesn't cough and splutter -- steady data is coming in, then it just drops the connection. systat doesn't show problems inbound; all packets received are delivered to the upper layer. But on outbound, there is consistent 'output drops': IP Output 7028 total packets sent 7028 - generated locally 314 - output drops As the number of outbound connections increases, the 'output drops' increases to around 10% of the total packets sent and maintains that ratio. There's no problems with network capacity. I've tried different servers, different network interfaces (bge, em), different kernel (7-RELEASE, 7-STABLE). Have also checked dev.bge.0.stats and dev.em.0.stats for CRC errors etc. which show no problems. 'netstat -m' doesn't show any reaching of mbuf and sbuf limits. The problem is seen in a dedicated, uncontended test environment. Can anyone explain why the packets are being dropped outbound, and how this could affect inbound TCP data in such an abrupt way? What can I do to solve this? Thanks, Mark ___ 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]
Re: kern/123347: [bge] bge1: watchdog timeout -- linkstate changedto DOWN
This issue is not a personal problem of mine. As I have alrady mentioned a lot of people have been reporting this issue without any answer. It's really sad that you've been unpolite and agressive to me just because I labelled the message HP. Does it really worth this overreaction? Well, let the people of reason answer. As for blocking me, I do respect your freedom of choice. Culture prevents me from responding otherwise! - Original Message - From: Steven Hartland [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Thursday, May 08, 2008 1:50 AM Subject: Re: kern/123347: [bge] bge1: watchdog timeout -- linkstate changedto DOWN Well given you have no consideration to for others and clearly think the world revolves around you problems so they every email you send must be flagged as important, welcome to my blocked senders list. - Original Message - From: [EMAIL PROTECTED] To: Steven Hartland [EMAIL PROTECTED] Cc: [EMAIL PROTECTED]; [EMAIL PROTECTED]; freebsd-net@FreeBSD.org Sent: Wednesday, May 07, 2008 11:01 PM Subject: Re: kern/123347: [bge] bge1: watchdog timeout -- linkstate changedto DOWN I guess it does, since this nightmere is being reported with different NICs and drivers including Intel NICs on em driver and 3Com NICs on bge and xl drivers on 6.3-RELEASE , 6-STABLE, 7.0-RELEAE and 7-STABLE. The mailing list if full of too many questions regarding this issue and no answer! If it realy doesn't worth a high priority flag, then I do appolgize and I shoud fall back to 4.11-RELEASE which worked on the same hardware like a sandwatch! This e.mail is private and confidential between Multiplay (UK) Ltd. and the person or entity to whom it is addressed. In the event of misdirection, the recipient is prohibited from using, copying, printing or otherwise disseminating it or any information contained in it. In the event of misdirection, illegible or incomplete transmission please telephone +44 845 868 1337 or return the E.mail to [EMAIL PROTECTED] ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Problems with netgraph
Oleksandr Samoylyk wrote: looks like UDP in PPP in GRE I think so. Should we hope for some progress in this direction in future? Probably not, unless someone is willing to come up to the table and commit to writing and maintaining a Netgraph node to demux GRE, although this is only shuffling the fanout elsewhere. If MPD is relying on raw sockets to demultiplex GRE, then this is what it's up against in terms of performance -- repeated acquisitions of the INP sleep lock, and context switches when the socket buffer low water mark is passed. It might have improved slightly in HEAD since the move to rwlocks. Like udp_input(), rip_input() suffers from the fact that the stack has to deal with delivering datagrams to potentially more than one socket, and there is no intermediate data structure to handle the fan-out -- it walks the entire inp list every time. If you look at the comments in udp_input() it's pretty clear this is a historical weakness in the BSD implementation. Windows, by the way, forces socket clients to explicitly request reception of broadcast datagrams as of Windows Server 2003, and multicasts are strictly delivered to group members only, which eliminates that problematic loop -- you can always maintain a tree of receivers that way. I'm happy to review patches if someone else commits to fixing it. cheers BMS ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: read() returns ETIMEDOUT on steady TCP connection
hi, the patch can not apply to 6.2, cound do a new patch for 6.2 or 6.3 ? I've looked at the code paths again. There are two possibilities: a) the mbuf allocator has some anomaly where it rejects memory requests but doesn't update the statistics (the code is there however). b) the error doesn't come from the mbuf allocation but from ip_output() and further down the chain. To differentiate please try this updated patch and report the log output again (don't forget to set net.inet.tcp.log_debug=1): http://people.freebsd.org/~andre/tcp_output-error-log.diff -- Andre Deng XueFeng wrote: hi I'am also meet this problem in my mss server(missey streaming server). one encoder push stream to mss, then run 100 client player playing the sream, as the client number increase, mss will occur this error sooner or later like this: I'am using kqueue, and will got a event with EV_EOF and fflags = ETIMEDOUT, if i ignore EV_EOF flag, then ETIMEDOUT will be return by read(2), and the tcpdump also show that server will send RST packet to encoder. Hello, I'm are having a trouble with TCP connections being dropped with read: Operation timed out. What is unusual is that this is happening right in the middle of sending a steady stream of data with no network congestion. The system is FreeBSD 7 and a bespoke streaming server with 1Gbit connection. The server receives a 192kbps inbound stream over TCP, and broadcasts it over a large number of TCP streams. With no visible or obvious pattern, the inbound read() fails with ETIMEDOUT. The likelihood of this happening seems to increase as the number of audience connections increases. It's happens every few minutes even with a small audience (eg. 300 outbound connections and about 60mbit). It doesn't cough and splutter -- steady data is coming in, then it just drops the connection. systat doesn't show problems inbound; all packets received are delivered to the upper layer. But on outbound, there is consistent 'output drops': IP Output 7028 total packets sent 7028 - generated locally 314 - output drops As the number of outbound connections increases, the 'output drops' increases to around 10% of the total packets sent and maintains that ratio. There's no problems with network capacity. I've tried different servers, different network interfaces (bge, em), different kernel (7-RELEASE, 7-STABLE). Have also checked dev.bge.0.stats and dev.em.0.stats for CRC errors etc. which show no problems. 'netstat -m' doesn't show any reaching of mbuf and sbuf limits. The problem is seen in a dedicated, uncontended test environment. Can anyone explain why the packets are being dropped outbound, and how this could affect inbound TCP data in such an abrupt way? What can I do to solve this? Thanks, Mark ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to [EMAIL PROTECTED] -- Deng XueFeng [EMAIL PROTECTED] ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to [EMAIL PROTECTED]
