Re: read() returns ETIMEDOUT on steady TCP connection
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]
Re: Not All Symbols Present in a Loadable Kernel Module
On Mon, 5 May 2008, Alexander Sack wrote: For my own edification, unless you specifically mark a function inline, will gcc really optimize them out? That seems a little overboard unless there is some compiler option that says its okay to do that. I guess that would be very easy to test if you do as you say, just sock away the function address pointer somewhere and you should be okay... This is a regression in gcc-4. The -O option says it. -O implies -funit-at-a-time, which allows inlining of functions irrespective of their order within a file and implies -finline-functions-called-once. Thus even plain -O removes most static functions that are only called once. This doesn't seem to be the problem with the bce functions, since some of the missing ones are called more than once. -O2 seems to remove even more functions, but I'm not sure of the details. It is a regression in FreeBSD-5(?) to use -O2 by default for kernels. This used to give mainly bloat, but it now breaks debugging (including stack traces) and profiling unless full debugging symbols are available and used. Only gdb uses full debugging symbols AFAIK, and at least for old versions of gdb on objects generated with -g -O2, it doesn't handle even explicit inline functions quite right (both explicit and inline functions get replaced by non-call instructions instructions and by symbols to say where the function call was, and debuggers have a hard time making this look like a function call so that stepping over the function call works, especially when -O2 reorders everything). [Context lost to top posting.] Bruce ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Not All Symbols Present in a Loadable Kernel Module
I thought that the inline switch was specific to C++ and C and not gcc, hence the standard for the language says to add the inline parameter to explicitly produce optimized code. Unless gcc is not standard, I don't see why the compiler would automatically optimize the coded function to inline. On Mon, 2008-05-05 at 14:06 -0400, Alexander Sack wrote: For my own edification, unless you specifically mark a function inline, will gcc really optimize them out? That seems a little overboard unless there is some compiler option that says its okay to do that. I guess that would be very easy to test if you do as you say, just sock away the function address pointer somewhere and you should be okay... -aps On Mon, May 5, 2008 at 12:32 PM, Kostik Belousov [EMAIL PROTECTED] wrote: On Mon, May 05, 2008 at 09:27:10AM -0700, David Christensen wrote: Yes, I'm building a debug kernel. I have the line listed above as well as the following: options KDB options DDB options GDB options INVARIANTS options INVARIANT_SUPPORT options WITNESS options WITNESS_SKIPSPIN Dave: What symbols can you not access exactly and how are you installing/setting up debugging? I just built a RELENG_7 with DDB and I'm able to access bce symbols without a problem. I can examine them and call them. I'm not using options GDB however, only KDB/DDB. I would: - Make sure you have the right if_bce.ko/if_bce.ko.symbols files generated/installed which contains the debug sections of your ko (from the objcopy calls during the build - the binary is stripped with a section pointer to the if_bce.ko.symbols file for debugging information I believe) - If you are using GDB, make sure its pointed to the right source base so it can retrieve symbol information correctly - If you are using GDB, stub it out and just use DDB to verify that your build is sane (it works for me!) - If all else fails, you can always build bce statically (just to move forward etc.) - Enable the kernel debugger as described above - Build the driver in the /usr/src/sys/modules/bce directory with the command make. - Run the command nm if_bce.ko | grep dump_stat in the same directory with the kernel module just built. In my case I only see a symbol for bce_dump_status_block, but there is a second routine called bce_dump_stats_block. In my working build there are 23 functions that start with bce_dump but only 8 are displayed with the command nm if_bce.ko | grep bce_dump. Of course, I also get the symbol not present error when I try to use any of those missing symbols through a call command in the debugger. Most likely, they are optimized out, gcc likes to inline once-called static functions. Aside from playing with the optimization options, the easiest way seems to use functions somewhere else, e.g., put the addresses into some table. Just guessing. ___ 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: Troubles with em on FreeBSD 7
A bit experiments and it's was detected that it is a netgraph related problem. Whom can I address the problem? Thanks to Paul. -- 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: Not All Symbols Present in a Loadable Kernel Module
On Tue, May 6, 2008 at 3:28 AM, Bruce Evans [EMAIL PROTECTED] wrote: On Mon, 5 May 2008, Alexander Sack wrote: For my own edification, unless you specifically mark a function inline, will gcc really optimize them out? That seems a little overboard unless there is some compiler option that says its okay to do that. I guess that would be very easy to test if you do as you say, just sock away the function address pointer somewhere and you should be okay... This is a regression in gcc-4. The -O option says it. -O implies -funit-at-a-time, which allows inlining of functions irrespective of their order within a file and implies -finline-functions-called-once. Thus even plain -O removes most static functions that are only called once. Thanks Bruce, I did some digging and all i can say is YIKES. Got to be careful with gcc optimizations. I suppose to be safe, bge could be compiled with -fno-inline-funcations-called-once to be safe. This doesn't seem to be the problem with the bce functions, since some of the missing ones are called more than once. Again, I would assume if you look at the symbols of the generated binary you should be able to figure out if you have a compiler issue or a debugger one! -aps ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Troubles with em on FreeBSD 7
Oleksandr Samoylyk wrote: A bit experiments and it's was detected that it is a netgraph related problem. Whom can I address the problem? Thanks to Paul. [EMAIL PROTECTED] send details and one of us will look at it.. ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to [EMAIL PROTECTED]
Problems with netgraph
Dear developers, Please read this thread: http://lists.freebsd.org/pipermail/freebsd-net/2008-May/017891.html I'm using no encryption and no compression in mpd, so netgraph should fly. It seems to get bad after 500 sessions... In FreeBSD 6 - it's swi1: net - 100% CPU In FreeBSD 7 - it's em0 taskq - 100% CPU After playing with it I can make guess that's a netgraph problem. Maybe it's a poor design in netgraph the way it handle its tables and it's is probably not designed to add so many interfaces. Might be there something in the source code I can edit to improve the table lookups or hash table or whatever netgraph use to store and process the node information and do the ppp/gre work. -- 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 пишет: Oleksandr Samoylyk wrote: Dear developers, Please read this thread: http://lists.freebsd.org/pipermail/freebsd-net/2008-May/017891.html I'm using no encryption and no compression in mpd, so netgraph should fly. It seems to get bad after 500 sessions... In FreeBSD 6 - it's swi1: net - 100% CPU In FreeBSD 7 - it's em0 taskq - 100% CPU After playing with it I can make guess that's a netgraph problem. Maybe it's a poor design in netgraph the way it handle its tables and it's is probably not designed to add so many interfaces. Might be there something in the source code I can edit to improve the table lookups or hash table or whatever netgraph use to store and process the node information and do the ppp/gre work. I can also offer a shell access to server in order to investigate the problem. # ngctl list ngctl: send msg: No buffer space available However: kern.ipc.maxpipekva=4 net.graph.maxalloc=8192 net.graph.maxdgram=256000 net.graph.recvspace=256000 -- 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: Dear developers, Please read this thread: http://lists.freebsd.org/pipermail/freebsd-net/2008-May/017891.html I'm using no encryption and no compression in mpd, so netgraph should fly. It seems to get bad after 500 sessions... In FreeBSD 6 - it's swi1: net - 100% CPU In FreeBSD 7 - it's em0 taskq - 100% CPU 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.. After playing with it I can make guess that's a netgraph problem. Maybe it's a poor design in netgraph the way it handle its tables and it's is probably not designed to add so many interfaces. how many? Might be there something in the source code I can edit to improve the table lookups or hash table or whatever netgraph use to store and process the node information and do the ppp/gre work. netgraph just had some work done on it for this exact reason, but you may be jumping the gun a bit.. ___ 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: Dear developers, Please read this thread: http://lists.freebsd.org/pipermail/freebsd-net/2008-May/017891.html I'm using no encryption and no compression in mpd, so netgraph should fly. It seems to get bad after 500 sessions... In FreeBSD 6 - it's swi1: net - 100% CPU In FreeBSD 7 - it's em0 taskq - 100% CPU 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.. After playing with it I can make guess that's a netgraph problem. Maybe it's a poor design in netgraph the way it handle its tables and it's is probably not designed to add so many interfaces. how many? more than 2500 Might be there something in the source code I can edit to improve the table lookups or hash table or whatever netgraph use to store and process the node information and do the ppp/gre work. netgraph just had some work done on it for this exact reason, but you may be jumping the gun a bit.. -- 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
Julian Elischer wrote: Oleksandr Samoylyk wrote: Dear developers, Please read this thread: http://lists.freebsd.org/pipermail/freebsd-net/2008-May/017891.html I'm using no encryption and no compression in mpd, so netgraph should fly. It seems to get bad after 500 sessions... In FreeBSD 6 - it's swi1: net - 100% CPU In FreeBSD 7 - it's em0 taskq - 100% CPU 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.. After playing with it I can make guess that's a netgraph problem. Maybe it's a poor design in netgraph the way it handle its tables and it's is probably not designed to add so many interfaces. how many? # vmstat -m | grep netgraph netgraph_msg 0 0K - 1355522 64,128,256,512,1024 netgraph_node 12110 3028K -28829 256 netgraph_hook 29648 3706K -66104 128 netgraph 8076 12663K -15209 64,256,1024,4096 netgraph_sock 4 1K - 5489 128 netgraph_path 1 1K - 728112 16,32 netgraph_mppc 0 0K -1 1024 netgraph_ksock 1349 169K - 3414 128 netgraph_iface 1346 169K - 2367 128 netgraph_ppp 1346 16152K - 2367 netgraph_bpf 16020 2003K -33296 128 # ifconfig -a | grep ng | wc -l 1341 I saw a peak with about 1900 ng interfaces. That was tooo sloo last pid: 39304; load averages: 1.12, 1.23, 1.20 up 0+01:15:38 22:39:04 93 processes: 10 running, 70 sleeping, 13 waiting CPU states: 0.3% user, 0.0% nice, 15.3% system, 3.1% interrupt, 81.3% idle Mem: 46M Active, 7772K Inact, 109M Wired, 128K Cache, 16M Buf, 7756M Free Swap: 4096M Total, 4096M Free PID USERNAME THR PRI NICE SIZERES STATE C TIME WCPU COMMAND 819 root 23 500 92764K 36424K select 1 0:00 207.18% mpd5 17 root1 171 ki31 0K16K RUN1 71:41 100.00% idle: cpu1 14 root1 171 ki31 0K16K CPU4 4 69:16 100.00% idle: cpu4 15 root1 171 ki31 0K16K CPU3 3 68:11 100.00% idle: cpu3 29 root1 -68- 0K16K CPU6 6 60:50 100.00% em0 taskq 18 root1 171 ki31 0K16K CPU0 0 71:58 97.17% idle: cpu0 16 root1 171 ki31 0K16K CPU2 2 68:13 95.65% idle: cpu2 11 root1 171 ki31 0K16K CPU7 7 66:23 86.38% idle: cpu7 13 root1 171 ki31 0K16K CPU5 5 65:28 71.97% idle: cpu5 19 root1 -44- 0K16K WAIT 5 19:53 31.59% swi1: net 30 root1 -68- 0K16K - 7 8:41 12.89% em1 taskq 12 root1 171 ki31 0K16K RUN6 12:41 0.00% idle: cpu6 20 root1 -32- 0K16K WAIT 3 1:12 0.00% swi4: clock # uname -v FreeBSD 7.0-STABLE #0: Mon May 5 01:11:23 EEST 2008 CPU: Intel(R) Xeon(R) CPU E5335 @ 2.00GHz (2000.01-MHz K8-class CPU) Origin = GenuineIntel Id = 0x6f7 Stepping = 7 Features=0xbfebfbffFPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CLFLUSH,DTS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE Features2=0x4e33dSSE3,RSVD2,MON,DS_CPL,VMX,TM2,SSSE3,CX16,xTPR,PDCM,DCA AMD Features=0x20100800SYSCALL,NX,LM AMD Features2=0x1LAHF Cores per package: 4 FreeBSD/SMP: Multiprocessor System Detected: 8 CPUs usable memory = 8580038656 (8182 MB) avail memory = 8292810752 (7908 MB) # ngctl list ngctl: send msg: No buffer space available # cat /boot/loader.conf loader_logo=beastie autoboot_delay=3 hw.em.rxd=1024 hw.em.txd=1024 net.inet.tcp.tcbhashsize=4096 kern.ipc.maxpipekva=3200 net.graph.recvspace=128000 net.graph.maxdgram=128000 Linux with poptop was running quit smoothly. I thought that netgraph would be fast as hell. -- 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: multiple routing tables review patch ready for simple testing.
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, ..)? + * For now the protocol indepedent versions are the same as the AF_INET ones + * but this will change.. just #define them at this time. + */ +#definein_rt_getifa(_a, _b)rt_getifa_fib(_a, _b) +#definein_rtalloc_ign(_a, _b, _c) rtalloc_ign_fib(_a, _b, _c) +#definein_rtalloc(_a, _b) rtalloc_fib(_a, _b) +#define in_rtalloc1(_a, _b, _c, _d)rtalloc1_fib(_a, _b, _c, _d) +#definein_rtioctl(_a, _b, _c) rtioctl_fib(_a, _b, _c) +#definein_rtredirect(_a, _b, _c, _d, _e, _f) \ + rtredirect_fib(_a, _b, _c, _d, _e, _f) +#define in_rtrequest(_a, _b, _c, _d, _e, _f, _g) \ + rtrequest_fib(_a, _b, _c, _d, _e, _f,_g) +#define in_rtrequest1(_a, _b, _c, _d) rtrequest1_fib(_a, _b, _c, _d) +#define in_rt_check(_a, _b, _c, _d)rt_check_fib(_a, _b, _c, _d) 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. /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: multiple routing tables review patch ready for simple testing.
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?
..)?
+ * For now the protocol indepedent versions are the same as the AF_INET
ones
+ * but this will change.. just #define them at this time.
+ */
+#definein_rt_getifa(_a, _b)rt_getifa_fib(_a, _b)
+#definein_rtalloc_ign(_a, _b, _c) rtalloc_ign_fib(_a, _b, _c)
+#definein_rtalloc(_a, _b) rtalloc_fib(_a, _b)
+#define in_rtalloc1(_a, _b, _c, _d)rtalloc1_fib(_a, _b, _c, _d)
+#definein_rtioctl(_a, _b, _c) rtioctl_fib(_a, _b, _c)
+#definein_rtredirect(_a, _b, _c, _d, _e, _f) \
+ rtredirect_fib(_a, _b, _c, _d,
_e, _f)
+#define in_rtrequest(_a, _b, _c, _d, _e, _f, _g) \
+ rtrequest_fib(_a, _b, _c, _d,
_e, _f,_g)
+#define in_rtrequest1(_a, _b, _c, _d) rtrequest1_fib(_a, _b,
_c, _d)
+#define in_rt_check(_a, _b, _c, _d)rt_check_fib(_a, _b, _c,
_d)
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..
In order to get away from having every protocol (existing or not)
from preallocating N fib heads (currently it is done in protocol
independent code) the protocols themselves need to know if they are
allocating multiple FIBS and how many. For this reason,
the protocol versions will eventually know where their own
fibs are stored and act on them as needed, allowing them to be
dynamically allocated. (as many as needed).
The methods for each protocol family woudl be pointed to in the
domain structure, and the protocol independent versions would look
them up that way and call them..
so the domain structure would include:
struct domain {
[...]
*(struct rtentry *dom_rtalloc)(mumble);
[...]
};
(or whatever the syntax is (I always have to look it up)
in netinet we would declare
struct domain inet_domain = {
[...]
in_rtalloc,
[...]
];
A new function find_domain(family)
makes a method independent way to find the domain structure for
any given PF/AF.
So rtalloc_fib would be:
struct rtentry *
rtalloc_fib( struct route *ro, int fib)
{
struct domain *dp;
dp = find_domain(ro-ro_dst.sa_family)
if (dp)
return (*(dp-dom_rtalloc)(ro, fib));
return (NULL);
}
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.
___
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 [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. -- David DeSimone == Network Admin == [EMAIL PROTECTED] This email message is intended for the use of the person to whom it has been sent, and may contain information that is confidential or legally protected. If you are not the intended recipient or have received this message in error, you are not authorized to copy, dis- tribute, or otherwise use this message or its attachments. Please notify the sender immediately by return e-mail and permanently delete this message and any attachments. Verio, Inc. makes no warranty that this email is error or virus free. Thank you. --Lawyer Bot 6000 ___ 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: 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 ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to [EMAIL PROTECTED]
