Re: tcp hostcache and ip fastforward for review
Andre Oppermann wrote: Makes sense. Can we ever have a packet that has a source address with INADDR_BROADCAST or IN_MULTICAST? I can't think of such a case. Can we ever have a packet with destination address INADDR_ANY? Maybe for BOOTP? But then the source address would be 0.0.0.0 too? IIRC, in case you have an IP-less interface and you want to subscribe it to some multicast address, the outgoing packet source address is 0.0.0.0. -- Daniel C. Sobral Gerência de Operações Divisão de Comunicação de Dados Coordenação de Segurança VIVO Centro Oeste Norte Fones: 55-61-313-7654/Cel: 55-61-9618-0904 E-mail: [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: tcp hostcache and ip fastforward for review
I've been thinking about this all day... Thus spake Jesper Skriver <[EMAIL PROTECTED]> [23:53:26 11/12/03: : > + /* : > +* Only unicast IP, not from loopback, no L2 or IP broadcast, : > +* no multicast, no INADDR_ANY : > +*/ : > + if ((m->m_pkthdr.rcvif->if_flags & IFF_LOOPBACK) || : > + (ntohl(ip->ip_src.s_addr) == (u_long)INADDR_BROADCAST) || : : #jesper : You will never see packets with a multicast source address. Do you mean: Any packets with a multicast source address will be dropped by the kernel before this point, or that no host will ever send a packet with a multicast source address? In the former, that's fine. In the latter, how does one guarantee that there isn't a malicious host out there sending spoofed multicast-source packets? - Damian ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: tcp hostcache and ip fastforward for review
Jesper Skriver wrote:
>
> On Thu, Nov 13, 2003 at 12:13:14AM +0100, Andre Oppermann wrote:
> > Jesper Skriver wrote:
> > >
> > > On Sun, Nov 09, 2003 at 05:19:07PM +0100, Andre Oppermann wrote:
> > > > Hello all,
> > > >
> > > > this patch contains three things (to be separated for committing):
> > ...
> > > > ip_fastforward
> > > >
> > > > - removes ip_flow forwarding code
> > > > - adds full direct process-to-completion IPv4 forwarding code
> > > > - handles ip fragmentation incl. hw support (ip_flow did not)
> > > > - supports ipfw and ipfilter (ip_flow did not)
> > > > - supports divert and ipfw fwd (ip_flow did not)
> > > > - drops anything it can't handle back to normal ip_input
> > >
> > > I have a few comments to this code, see inline, look for #jesper
> >
> > Answers also inline. [All whitespace bugs are fixed and omitted here]
>
> One comment at the bottom.
>
> > > Apart from that it looks good.
> >
> > Thanks for reviewing!
> >
> > > /Jesper
> > >
> > > > +int
> > > > +ip_fastforward(struct mbuf *m)
> > > > +{
> > ...
> > > > +
> > > > + /*
> > > > + * Only unicast IP, not from loopback, no L2 or IP broadcast,
> > > > + * no multicast, no INADDR_ANY
> > > > + */
> > > > + if ((m->m_pkthdr.rcvif->if_flags & IFF_LOOPBACK) ||
> > > > + (ntohl(ip->ip_src.s_addr) == (u_long)INADDR_BROADCAST) ||
> > >
> > > #jesper
> > > You will never see packets with a multicast source address.
> >
> > I hope so but we can never be sure. Here we look at what we've got
> > straight from the wire. Everything is possible there. I only need
> > to craft an apropriate packet...
>
> True, but do we really care if forwarded such a packet ?
Yes, never forward anything that should not be. Stop the problem
right here instead of letting it become a problem somewhere else.
> And if we want to check, we should just drop it directly instead of
> giving the packet to ip_input.
Makes sense.
Can we ever have a packet that has a source address with INADDR_BROADCAST
or IN_MULTICAST? I can't think of such a case.
Can we ever have a packet with destination address INADDR_ANY? Maybe
for BOOTP? But then the source address would be 0.0.0.0 too?
With fallback to ip_input() in all those cases I wanted to make sure that
I don't break any obscure hack or protocol I didn't think of.
--
Andre
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: tcp hostcache and ip fastforward for review
On Thu, Nov 13, 2003 at 12:13:14AM +0100, Andre Oppermann wrote:
> Jesper Skriver wrote:
> >
> > On Sun, Nov 09, 2003 at 05:19:07PM +0100, Andre Oppermann wrote:
> > > Hello all,
> > >
> > > this patch contains three things (to be separated for committing):
> ...
> > > ip_fastforward
> > >
> > > - removes ip_flow forwarding code
> > > - adds full direct process-to-completion IPv4 forwarding code
> > > - handles ip fragmentation incl. hw support (ip_flow did not)
> > > - supports ipfw and ipfilter (ip_flow did not)
> > > - supports divert and ipfw fwd (ip_flow did not)
> > > - drops anything it can't handle back to normal ip_input
> >
> > I have a few comments to this code, see inline, look for #jesper
>
> Answers also inline. [All whitespace bugs are fixed and omitted here]
One comment at the bottom.
> > Apart from that it looks good.
>
> Thanks for reviewing!
>
> > /Jesper
> >
> > > +int
> > > +ip_fastforward(struct mbuf *m)
> > > +{
> ...
> > > +
> > > + /*
> > > + * Only unicast IP, not from loopback, no L2 or IP broadcast,
> > > + * no multicast, no INADDR_ANY
> > > + */
> > > + if ((m->m_pkthdr.rcvif->if_flags & IFF_LOOPBACK) ||
> > > + (ntohl(ip->ip_src.s_addr) == (u_long)INADDR_BROADCAST) ||
> >
> > #jesper
> > You will never see packets with a multicast source address.
>
> I hope so but we can never be sure. Here we look at what we've got
> straight from the wire. Everything is possible there. I only need
> to craft an apropriate packet...
True, but do we really care if forwarded such a packet ?
And if we want to check, we should just drop it directly instead of
giving the packet to ip_input.
/Jesper
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: tcp hostcache and ip fastforward for review
Jesper Skriver wrote:
>
> On Sun, Nov 09, 2003 at 05:19:07PM +0100, Andre Oppermann wrote:
> > Hello all,
> >
> > this patch contains three things (to be separated for committing):
...
> > ip_fastforward
> >
> > - removes ip_flow forwarding code
> > - adds full direct process-to-completion IPv4 forwarding code
> > - handles ip fragmentation incl. hw support (ip_flow did not)
> > - supports ipfw and ipfilter (ip_flow did not)
> > - supports divert and ipfw fwd (ip_flow did not)
> > - drops anything it can't handle back to normal ip_input
>
> I have a few comments to this code, see inline, look for #jesper
Answers also inline. [All whitespace bugs are fixed and omitted here]
> Apart from that it looks good.
Thanks for reviewing!
> /Jesper
>
> > +int
> > +ip_fastforward(struct mbuf *m)
> > +{
...
> > +
> > + /*
> > + * Only unicast IP, not from loopback, no L2 or IP broadcast,
> > + * no multicast, no INADDR_ANY
> > + */
> > + if ((m->m_pkthdr.rcvif->if_flags & IFF_LOOPBACK) ||
> > + (ntohl(ip->ip_src.s_addr) == (u_long)INADDR_BROADCAST) ||
>
> #jesper
> You will never see packets with a multicast source address.
I hope so but we can never be sure. Here we look at what we've got
straight from the wire. Everything is possible there. I only need
to craft an apropriate packet...
> > + (ntohl(ip->ip_dst.s_addr) == (u_long)INADDR_BROADCAST) ||
> > + (IN_MULTICAST(ntohl(ip->ip_src.s_addr))) ||
> > + (IN_MULTICAST(ntohl(ip->ip_dst.s_addr))) ||
> > + (ip->ip_dst.s_addr == INADDR_ANY) )
> > + goto fallback;
...
> > + /*
> > + * Or is it for a local IP broadcast address on this host?
> > + */
> > + if (m->m_pkthdr.rcvif->if_flags & IFF_BROADCAST) {
> > + TAILQ_FOREACH(ifa, &m->m_pkthdr.rcvif->if_addrhead, ifa_link) {
> > + if (ifa->ifa_addr->sa_family != AF_INET)
> > + continue;
> > + ia = ifatoia(ifa);
> > + if (ia->ia_netbroadcast.s_addr == ip->ip_dst.s_addr)
> > + goto fallback;
> > + if (satosin(&ia->ia_broadaddr)->sin_addr.s_addr ==
> > + ip->ip_dst.s_addr)
> > + goto fallback;
> > + continue;
> > +fallback:
> > + /* drop the packet back to netisr */
> > + ip->ip_len = htons(ip->ip_len);
> > + ip->ip_off = htons(ip->ip_off);
> > + return 0;
> > + }
> > + }
> > + ipstat.ips_total++;
>
> #jesper
> If we stored special "for us" /32 routes in the routing table for
> addresses configured on this host, we could avoid the above 2 loops,
> which can quite expensive.
Good idea. I will look at that after 5.2 code freeze.
> These special routes will simply mean that the packet is for us, and
> needs to given to ip_input
>
> > + /**
> > + ** Third: incoming packet firewall processing
> > + **/
> > +
> > + odest = dest = ip->ip_dst.s_addr;
>
> #jesper
> You could save a few cycles by doing
Well, you're right. However I don't think it makes any difference
and I'd like to keep it the current way for clarity and ease of reading
and understanding the code.
> #ifdef PFIL_HOOKS
> odest = ip->ip_dst.s_addr;
> /*
> * Run through list of ipfilter hooks for input packets
> */
> if (pfil_run_hooks(&inet_pfil_hook, &m, m->m_pkthdr.rcvif, PFIL_IN) ||
> m == NULL)
> return 1;
>
> M_ASSERTVALID(m);
> M_ASSERTPKTHDR(m);
>
> ip = mtod(m, struct ip *); /* if m changed during fw processing */
> dest = ip->ip_dst.s_addr;
> #else
> odest = dest = ip->ip_dst.s_addr;
> #endif
>
> Thus avoiding writing to dest twice.
>
> > +#ifdef PFIL_HOOKS
> > + /*
> > + * Run through list of ipfilter hooks for input packets
> > + */
> > + if (pfil_run_hooks(&inet_pfil_hook, &m, m->m_pkthdr.rcvif, PFIL_IN) ||
> > + m == NULL)
> > + return 1;
> > +
> > + M_ASSERTVALID(m);
> > + M_ASSERTPKTHDR(m);
> > +
> > + ip = mtod(m, struct ip *); /* if m changed during fw processing */
> > + dest = ip->ip_dst.s_addr;
> > +#endif
...
> > +passin:
> > + ip = mtod(m, struct ip *); /* if m changed during fw processing */
> > +
> > + /*
> > + * Destination address changed?
> > + */
> > + if (odest != dest) {
> > + /*
> > + * Is it now for a local address on this host?
> > + */
> > + LIST_FOREACH(ia, INADDR_HASH(ip->ip_dst.s_addr), ia_hash) {
> > + if (IA_SIN(ia)->sin_addr.s_addr == ip->ip_dst.s_addr)
> > + goto forwardlocal;
> > + }
>
> #jesper
>
> Same comment as above - and do we really want to see if the original
> d
Re: tcp hostcache and ip fastforward for review
On Sun, Nov 09, 2003 at 05:19:07PM +0100, Andre Oppermann wrote:
> Hello all,
>
> this patch contains three things (to be separated for committing):
>
> tcp_hostcache
>
> - removes protocol cloning from routing table (IPv4+6)
> - removes rtentry pointer from inpcb and in6pcb
> - removes ip route cache in ip_input.c (locking much easier)
> - removes most (tcp specific) metrics from rtentry metrics
> - adds a hostcache table which carries the metrics for tcp
> - works transparently for IPv4 and IPv6
> - is designed for concurrent access in SMP environments
> - significant reduction of routing table size (no cloning anymore)
> - eases many routing table locking situations in ip/tcp code
>
> ip_fastforward
>
> - removes ip_flow forwarding code
> - adds full direct process-to-completion IPv4 forwarding code
> - handles ip fragmentation incl. hw support (ip_flow did not)
> - supports ipfw and ipfilter (ip_flow did not)
> - supports divert and ipfw fwd (ip_flow did not)
> - drops anything it can't handle back to normal ip_input
I have a few comments to this code, see inline, look for #jesper
Apart from that it looks good.
/Jesper
> +int
> +ip_fastforward(struct mbuf *m)
> +{
> + struct ip *ip;
> + struct mbuf *m0 = NULL;
> +#ifdef IPDIVERT
> + struct ip *tip;
> + struct mbuf *teem = NULL;
> +#endif
> + struct mbuf *tag = NULL;
> + struct route ro;
> + struct sockaddr_in *dst = NULL;
> + struct in_ifaddr *ia = NULL;
> + struct ifaddr *ifa = NULL;
> + struct ifnet *ifp = NULL;
> + struct ip_fw_args args;
> + in_addr_t odest, dest;
> + u_short sum;
> + int hlen;
> + int error = 0;
> + int ipfw;
> +
> + /*
> + * Are we active and forwarding packets?
> + */
> + if (!ipfastforward_active || !ipforwarding)
> + return 0;
> +
> + /*
> + * If there is any MT_TAG we fall back to ip_input because we can't
> + * handle TAGs here.
> + */
> + if (m && m->m_type == MT_TAG)
> + return 0;
> +
> + M_ASSERTVALID(m);
> + M_ASSERTPKTHDR(m);
> +
[...]
> +
> + /*
> + * Only unicast IP, not from loopback, no L2 or IP broadcast,
> + * no multicast, no INADDR_ANY
> + */
> + if ((m->m_pkthdr.rcvif->if_flags & IFF_LOOPBACK) ||
> + (ntohl(ip->ip_src.s_addr) == (u_long)INADDR_BROADCAST) ||
#jesper
You will never see packets with a multicast source address.
> + (ntohl(ip->ip_dst.s_addr) == (u_long)INADDR_BROADCAST) ||
> + (IN_MULTICAST(ntohl(ip->ip_src.s_addr))) ||
> + (IN_MULTICAST(ntohl(ip->ip_dst.s_addr))) ||
> + (ip->ip_dst.s_addr == INADDR_ANY) )
> + goto fallback;
> +
> + /*
> + * Is it for a local address on this host?
> + */
> + LIST_FOREACH(ia, INADDR_HASH(ip->ip_dst.s_addr), ia_hash) {
> + if (IA_SIN(ia)->sin_addr.s_addr == ip->ip_dst.s_addr) {
> + goto fallback;
> + }
> + }
> +
> + /*
> + * Or is it for a local IP broadcast address on this host?
> + */
> + if (m->m_pkthdr.rcvif->if_flags & IFF_BROADCAST) {
> + TAILQ_FOREACH(ifa, &m->m_pkthdr.rcvif->if_addrhead, ifa_link) {
> + if (ifa->ifa_addr->sa_family != AF_INET)
> + continue;
> + ia = ifatoia(ifa);
> + if (ia->ia_netbroadcast.s_addr == ip->ip_dst.s_addr)
> + goto fallback;
> + if (satosin(&ia->ia_broadaddr)->sin_addr.s_addr ==
> + ip->ip_dst.s_addr)
> + goto fallback;
> + continue;
> +fallback:
> + /* drop the packet back to netisr */
> + ip->ip_len = htons(ip->ip_len);
> + ip->ip_off = htons(ip->ip_off);
> + return 0;
> + }
> + }
> + ipstat.ips_total++;
#jesper
If we stored special "for us" /32 routes in the routing table for
addresses configured on this host, we could avoid the above 2 loops,
which can quite expensive.
These special routes will simply mean that the packet is for us, and
needs to given to ip_input
> + /**
> + ** Third: incoming packet firewall processing
> + **/
> +
> + odest = dest = ip->ip_dst.s_addr;
#jesper
You could save a few cycles by doing
#ifdef PFIL_HOOKS
odest = ip->ip_dst.s_addr;
/*
* Run through list of ipfilter hooks for input packets
*/
if (pfil_run_hooks(&inet_pfil_hook, &m, m->m_pkthdr.rcvif, PFIL_IN) ||
m == NULL)
return 1;
M_ASSERTVALID(m);
M_ASSERTPKTHDR(m);
ip = mtod(m, struct ip *); /* if m changed during fw processing */
dest = ip->ip_dst.s_addr;
#else
odest = dest = ip->ip_dst.s_addr;
#endif
Thus avoiding writing to dest twice.
> +#ifdef PFIL_HOOKS
>
Re: tcp hostcache and ip fastforward for review
Hajimu UMEMOTO wrote:
>
> Hi,
>
> > On Wed, 12 Nov 2003 16:22:38 +0100
> > Andre Oppermann <[EMAIL PROTECTED]> said:
>
> oppermann> Ok, I found the bug. It was in the ipv6 hash function where I made
> oppermann> a mistake with the hashmask.
> oppermann> The updated patch is here:
> oppermann> http://www.nrg4u.com/freebsd/tcphostcache+ipfastforward-20031112.patch
> oppermann> Could you try again please?
>
> It does repeatable panic. Unfortunately, my laptop hanguped during
> dumping core, and I couldn't get core. So, I copied the output from
> ddb by hand.
-snip-
> Stopped at in6_selecthlim+0x35:cmpl$0,0x1c(%esi)
> db> trace
> in6_selecthlim(0,0,28,0,fadd8ac9) at in6_selecthlim+0x35
> syncache_respond(c3f6f000,c19a0600,1,c19a0600,0) at syncache_respond+0x31c
Grmpf... That is a logic error by me. Please add the following check
on line 707 in the patched netinet6/in6_src.c:
else if (in6p && !IN6_IS_ADDR_UNSPECIFIED(&in6p->in6p_faddr)) {
^^
Thank you for your effort in testing my changes!
--
Andre
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: tcp hostcache and ip fastforward for review
Hi, > On Wed, 12 Nov 2003 16:22:38 +0100 > Andre Oppermann <[EMAIL PROTECTED]> said: oppermann> Ok, I found the bug. It was in the ipv6 hash function where I made oppermann> a mistake with the hashmask. oppermann> The updated patch is here: oppermann> http://www.nrg4u.com/freebsd/tcphostcache+ipfastforward-20031112.patch oppermann> Could you try again please? It does repeatable panic. Unfortunately, my laptop hanguped during dumping core, and I couldn't get core. So, I copied the output from ddb by hand. Fatal trap 12: page fault while in kernel mode fault virtual address = 0x1c fault code = supervisor read, page not present instruction pointer = 0x8:0xc05b68c5 stack pointer = 0x10:0xd208ea28 frame pointer = 0x10:0xd208ea64 code segment= base 0x0, limit 0x, type 0x1b = DPL 0, pres 1, def32 1, gran 1 processor eflags= interrupt enabled, resume, IOPL = 0 current process = 27 (swi1: net) kernel: type 12 trap, code=0 Stopped at in6_selecthlim+0x35:cmpl$0,0x1c(%esi) db> trace in6_selecthlim(0,0,28,0,fadd8ac9) at in6_selecthlim+0x35 syncache_respond(c3f6f000,c19a0600,1,c19a0600,0) at syncache_respond+0x31c syncache_add(d208eb80,d208ebf4,c1fc4836,d208eb4c,c19a0600) at syncache_add+0x4f4 tcp_input(c19a0600,28,0,d208ec40,6) at tcp_input+0xdae tcp6_input(d208ec84,d208ec60,6,d208ec84,28) at tcp6_input+0xf5 ip6_input(c19a0600,d018930f,39d40a1e,c0724474,0) at ip6_input+0xc18 netisr_processqueue(c06f0484,aa,7b1c1ccb,351110b4,c050250d) at netisr_processqueue+0xd9 swi_net(0,0,0,0,c199254c) at swi_net+0xd9 ithread_loop(c1988580,d208ed48,4d,55ff44fd,0) at ithread_loop+0x1d8 fork_exit(c04e4d90,c1988580,d208ed48) at fork_exit+0x80 fork_trampoline() at fork_trampoline+0x8 --- trap 0x1, eip = 0, esp = 0xd208ed7c, ebp = 0 --- db> Sincerely, -- Hajimu UMEMOTO @ Internet Mutual Aid Society Yokohama, Japan [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED],jp.}FreeBSD.org http://www.imasy.org/~ume/ ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: tcp hostcache and ip fastforward for review
Hajimu UMEMOTO wrote: > > Hi, > > > On Tue, 11 Nov 2003 19:26:41 +0100 > > Andre Oppermann <[EMAIL PROTECTED]> said: > > oppermann> I have fixed the panic. It was a stupid braino in the test whether > oppermann> we have to free the allocated route. It was trying to free a null > oppermann> pointer route which obviously doesn't work. :-^ > > oppermann> The updated patch is here: > > oppermann> http://www.nrg4u.com/freebsd/tcphostcache+ipfastforward-2003.patch > > oppermann> If you could try again please? > > It panics at another point on boot. > (kgdb) frame 24 > #24 0xc058e637 in tcp_hc_getmtu (inc=0x0) > at /usr/home/ume/cvs/freefall/current/src/sys/netinet/tcp_hostcache.c:420 > 420 hc_entry = tcp_hc_lookup(inc); > (kgdb) Ok, I found the bug. It was in the ipv6 hash function where I made a mistake with the hashmask. The updated patch is here: http://www.nrg4u.com/freebsd/tcphostcache+ipfastforward-20031112.patch Could you try again please? I have organized a second IPv6 capable machine (OpenBSD) for testing and I was able to ssh from my development machine to the OpenBSD via IPv6 tcp connection. I hope the last update has ironed out all ip6 bugs now. -- Andre ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: tcp hostcache and ip fastforward for review
Hajimu UMEMOTO wrote: > > Hi, > > > On Tue, 11 Nov 2003 19:26:41 +0100 > > Andre Oppermann <[EMAIL PROTECTED]> said: > > oppermann> I have fixed the panic. It was a stupid braino in the test whether > oppermann> we have to free the allocated route. It was trying to free a null > oppermann> pointer route which obviously doesn't work. :-^ > > oppermann> The updated patch is here: > > oppermann> http://www.nrg4u.com/freebsd/tcphostcache+ipfastforward-2003.patch > > oppermann> If you could try again please? > > It panics at another point on boot. > (kgdb) frame 24 > #24 0xc058e637 in tcp_hc_getmtu (inc=0x0) > at /usr/home/ume/cvs/freefall/current/src/sys/netinet/tcp_hostcache.c:420 > 420 hc_entry = tcp_hc_lookup(inc); > (kgdb) Did the panic message say "tcp_hc_lookup with NULL in_conninfo pointer"? I can't find why inc can be possibly NULL because its fresh and directly on the stack. But I'm too tired right now (that's probably why I don't see atm). Next try tomorrow morning (mid-European time). -- Andre ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: tcp hostcache and ip fastforward for review
Ken Menzel wrote: > > Hi Andre, >Your patch applies just fine for me now on Oct 10th current > sources. Everything seems to be working fine on dual processor Dell > 2500 with SMP kernel. This is a network backup machine. I don't see > any problems, just as fast as always and seems to be solid so far, > it has only been running a few hours. I ran some network backups to > this server and ssh sessions out. Great! Many thanks for testing and feedback! -- Andre > Thanks Ken > riker# sysctl -a net.inet.tcp.hostcache.list > net.inet.tcp.hostcache.list: > IP addressMTU SSTRESH RTT RTTVAR BANDWIDTH CWND > SENDPIPE RECVPIPE HITS UPD EXP > 209.123.219.10 00 14ms 9ms 1805600 6516 > 0043 3600 > 207.99.22.1900 17ms 13ms 109840065535 > 0043 600 > > - Original Message - > From: "Andre Oppermann" <[EMAIL PROTECTED]> > To: <[EMAIL PROTECTED]>; <[EMAIL PROTECTED]> > Cc: <[EMAIL PROTECTED]>; <[EMAIL PROTECTED]>; <[EMAIL PROTECTED]> > Sent: Sunday, November 09, 2003 11:19 AM > Subject: tcp hostcache and ip fastforward for review > > > Hello all, > > > > this patch contains three things (to be separated for committing): > > > > tcp_hostcache > > > > - removes protocol cloning from routing table (IPv4+6) > > - removes rtentry pointer from inpcb and in6pcb > ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: tcp hostcache and ip fastforward for review
Hi,
> On Tue, 11 Nov 2003 19:26:41 +0100
> Andre Oppermann <[EMAIL PROTECTED]> said:
oppermann> I have fixed the panic. It was a stupid braino in the test whether
oppermann> we have to free the allocated route. It was trying to free a null
oppermann> pointer route which obviously doesn't work. :-^
oppermann> The updated patch is here:
oppermann> http://www.nrg4u.com/freebsd/tcphostcache+ipfastforward-2003.patch
oppermann> If you could try again please?
It panics at another point on boot.
panic: page fault
panic messages:
---
Fatal trap 12: page fault while in kernel mode
fault virtual address = 0x7d1efae8
fault code = supervisor write, page not present
instruction pointer = 0x8:0xc058e2bf
stack pointer = 0x10:0xd2e5e84c
frame pointer = 0x10:0xd2e5e874
code segment= base 0x0, limit 0xf, type 0x1b
= DPL 0, pres 1, def32 1, gran 1
processor eflags= interrupt enabled, resume, IOPL = 0
current process = 10384 (racoon)
trap number = 12
panic: page fault
#0 doadump ()
at /usr/home/ume/cvs/freefall/current/src/sys/kern/kern_shutdown.c:240
240 dumping++;
(kgdb) bt
#0 doadump ()
at /usr/home/ume/cvs/freefall/current/src/sys/kern/kern_shutdown.c:240
#1 0xc04fad80 in boot (howto=260)
at /usr/home/ume/cvs/freefall/current/src/sys/kern/kern_shutdown.c:372
#2 0xc04fb168 in panic ()
at /usr/home/ume/cvs/freefall/current/src/sys/kern/kern_shutdown.c:550
#3 0xc05441e1 in bremfreel (bp=0xcae402a8)
at /usr/home/ume/cvs/freefall/current/src/sys/kern/vfs_bio.c:647
#4 0xc05440eb in bremfree (bp=0x0)
at /usr/home/ume/cvs/freefall/current/src/sys/kern/vfs_bio.c:629
#5 0xc054f1a9 in cluster_wbuild (vp=0xc3c1ca44, size=16384, start_lbn=1,
len=1) at /usr/home/ume/cvs/freefall/current/src/sys/kern/vfs_cluster.c:804
#6 0xc054ecf1 in cluster_write (bp=0xcae402a8, filesize=32768, seqcount=127)
at /usr/home/ume/cvs/freefall/current/src/sys/kern/vfs_cluster.c:590
#7 0xc05fb428 in ffs_write (ap=0xd2e5e33c)
at /usr/home/ume/cvs/freefall/current/src/sys/ufs/ffs/ffs_vnops.c:748
#8 0xc062cd53 in vnode_pager_generic_putpages (vp=0xc3c1ca44, m=0xd2e5e480,
bytecount=4096, flags=12, rtvals=0xd2e5e440) at vnode_if.h:432
#9 0xc05507c0 in vop_stdputpages (ap=0x0)
at /usr/home/ume/cvs/freefall/current/src/sys/kern/vfs_default.c:813
#10 0xc054fb98 in vop_defaultop (ap=0x0)
at /usr/home/ume/cvs/freefall/current/src/sys/kern/vfs_default.c:161
#11 0xc060a208 in ufs_vnoperate (ap=0x0)
at /usr/home/ume/cvs/freefall/current/src/sys/ufs/ufs/ufs_vnops.c:2793
#12 0xc062ca88 in vnode_pager_putpages (object=0xc3c20b90, m=0x0, count=0,
sync=12, rtvals=0x0) at vnode_if.h:1357
#13 0xc0623b1e in vm_pageout_flush (mc=0xd2e5e480, count=1, flags=12)
at /usr/home/ume/cvs/freefall/current/src/sys/vm/vm_pager.h:146
#14 0xc061dac6 in vm_object_page_collect_flush (object=0xc3c20b90,
p=0xc14e54f0, curgeneration=1, pagerflags=12)
---Type to continue, or q to quit---
at /usr/home/ume/cvs/freefall/current/src/sys/vm/vm_object.c:948
#15 0xc061d4be in vm_object_page_clean (object=0xc3c20b90, start=7, end=0,
flags=4) at /usr/home/ume/cvs/freefall/current/src/sys/vm/vm_object.c:747
#16 0xc055d5b9 in vfs_msync (mp=0xc3a4ac00, flags=2)
at /usr/home/ume/cvs/freefall/current/src/sys/kern/vfs_subr.c:3235
#17 0xc055e769 in sync (td=0xc06e6fa0, uap=0x0)
at /usr/home/ume/cvs/freefall/current/src/sys/kern/vfs_syscalls.c:140
#18 0xc04fa88d in boot (howto=256)
at /usr/home/ume/cvs/freefall/current/src/sys/kern/kern_shutdown.c:281
#19 0xc04fb168 in panic ()
at /usr/home/ume/cvs/freefall/current/src/sys/kern/kern_shutdown.c:550
#20 0xc0662326 in trap_fatal (frame=0xd2e5e80c, eva=0)
at /usr/home/ume/cvs/freefall/current/src/sys/i386/i386/trap.c:821
#21 0xc0661fc2 in trap_pfault (frame=0xd2e5e80c, usermode=0, eva=2099182312)
at /usr/home/ume/cvs/freefall/current/src/sys/i386/i386/trap.c:735
#22 0xc0661b15 in trap (frame=
{tf_fs = 24, tf_es = -756744176, tf_ds = -1067319280, tf_edi = -756684608,
tf_esi = 2099182272, tf_ebp = -756684684, tf_isp = -756684744, tf_ebx = 1500, tf_edx =
-1014756864, tf_ecx = -1014277120, tf_eax = 4, tf_trapno = 12, tf_err = 2, tf_eip =
-1067916609, tf_cs = 8, tf_eflags = 68103, tf_esp = -756684268, tf_ss = -1013112832})
at /usr/home/ume/cvs/freefall/current/src/sys/i386/i386/trap.c:420
#23 0xc0652e08 in calltrap () at {standard input}:94
#24 0xc058e637 in tcp_hc_getmtu (inc=0x0)
at /usr/home/ume/cvs/freefall/current/src/sys/netinet/tcp_hostcache.c:420
#25 0xc05bce17 in ip6_getpmtu (ro_pmtu=0x7d1efac0, ro=0x0, ifp=0xc38b5c00,
dst=0xd2e5e9e0, mtup=0x0, alwaysfragp=0xd2e5e980)
at /usr/home/ume/cvs/freefall/current/src/sys/netinet6/ip6_output.c:1400
#26 0xc05bbf1f in ip6_output (m0=0xd2e5eaa0, opt=0xd2e5eaa0, ro=0xd2e5ea10,
flags=0, im6o=0x0, ifpp=0x0, inp=0xc3b2d900)
---Type to continue, or q to qui
Re: tcp hostcache and ip fastforward for review
Hajimu UMEMOTO wrote: > > Hi, > > > On Sun, 09 Nov 2003 17:19:07 +0100 > > Andre Oppermann <[EMAIL PROTECTED]> said: > > oppermann> The patch is here (relative to -CURRENT as of 2003-11-09): > > oppermann> http://www.nrg4u.com/freebsd/tcphostcache+ipfastforward-20031109.patch > > It panics at boot around invoking rtsol(8): I have fixed the panic. It was a stupid braino in the test whether we have to free the allocated route. It was trying to free a null pointer route which obviously doesn't work. :-^ The updated patch is here: http://www.nrg4u.com/freebsd/tcphostcache+ipfastforward-2003.patch If you could try again please? -- Andre ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: tcp hostcache and ip fastforward for review
Hi, > On Tue, 11 Nov 2003 18:06:05 +0100 > Andre Oppermann <[EMAIL PROTECTED]> said: oppermann> However there is a problem in netkey/key.c with the static variable oppermann> ipsec_esp_auth which is unused if IPSEC_ESP is not defined. Thanks. I've just committed to define ipsec_esp_auth only when IPSEC_ESP is defined. Sincerely, -- Hajimu UMEMOTO @ Internet Mutual Aid Society Yokohama, Japan [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED],jp.}FreeBSD.org http://www.imasy.org/~ume/ ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: tcp hostcache and ip fastforward for review
Hajimu UMEMOTO wrote:
>
> Hi,
>
> > On Sun, 09 Nov 2003 17:19:07 +0100
> > Andre Oppermann <[EMAIL PROTECTED]> said:
>
> oppermann> The patch is here (relative to -CURRENT as of 2003-11-09):
> oppermann> http://www.nrg4u.com/freebsd/tcphostcache+ipfastforward-20031109.patch
>
> The patch cannot be compiled:
>
> cc -c -O -pipe -march=pentium3 -Wall -Wredundant-decls -Wnested-externs
> -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual
> -fformat-extensions -std=c99 -g -nostdinc -I- -I.
> -I/usr/home/ume/cvs/freefall/current/src/sys
> -I/usr/home/ume/cvs/freefall/current/src/sys/contrib/dev/acpica
> -I/usr/home/ume/cvs/freefall/current/src/sys/contrib/ipfilter
> -I/usr/home/ume/cvs/freefall/current/src/sys/contrib/dev/ath
> -I/usr/home/ume/cvs/freefall/current/src/sys/contrib/dev/ath/freebsd
> -I/usr/home/ume/cvs/freefall/current/src/sys/contrib/ngatm -D_KERNEL -include
> opt_global.h -fno-common -finline-limit=15000 -fno-strict-aliasing
> -mno-align-long-strings -mpreferred-stack-boundary=2 -ffreestanding -Werror
> /usr/home/ume/cvs/freefall/current/src/sys/netinet/ip_input.c
> /usr/home/ume/cvs/freefall/current/src/sys/netinet/ip_input.c: In function
> `ip_forward':
> /usr/home/ume/cvs/freefall/current/src/sys/netinet/ip_input.c:1960: warning:
> implicit declaration of function `ipsec_getpolicybyaddr'
> /usr/home/ume/cvs/freefall/current/src/sys/netinet/ip_input.c:1963: warning:
> assignment makes pointer from integer without a cast
> *** Error code 1
>
> There is no ipsec_getpolicybyaddr() for IPSEC. And, #ifdef is
> slightly complex.
I've applied you fix. This was an oversight by me when collapsing
the two IPSEC and FAST_IPSEC ifdef's.
However there is a problem in netkey/key.c with the static variable
ipsec_esp_auth which is unused if IPSEC_ESP is not defined.
--
Andre
> I don't tested it actually, yet.
>
> --- sys/netinet/ip_input.c.orig Wed Nov 12 00:08:42 2003
> +++ sys/netinet/ip_input.c Wed Nov 12 00:18:50 2003
> @@ -1957,10 +1957,17 @@
> int ipsechdr;
> struct route *ro;
>
> +#ifdef IPSEC
> + sp = ipsec4_getpolicybyaddr(mcopy,
> + IPSEC_DIR_OUTBOUND,
> + IP_FORWARDING,
> + &ipsecerror);
> +#else
> sp = ipsec_getpolicybyaddr(mcopy,
>IPSEC_DIR_OUTBOUND,
>IP_FORWARDING,
>&ipsecerror);
> +#endif
>
> if (sp != NULL) {
> /* count IPsec header size */
> @@ -1995,13 +2002,11 @@
> #else
> KEY_FREESP(&sp);
> #endif
> - ipstat.ips_cantfrag++;
> - break;
> - } else
> -#endif /*IPSEC || FAST_IPSEC*/
> - destifp = ia->ia_ifp;
> -#if defined(IPSEC) || defined(FAST_IPSEC)
> + } else
> + destifp = ia->ia_ifp;
> }
> +#else
> + destifp = ia->ia_ifp;
> #endif /*IPSEC || FAST_IPSEC*/
> ipstat.ips_cantfrag++;
> break;
>
> Sincerely,
>
> --
> Hajimu UMEMOTO @ Internet Mutual Aid Society Yokohama, Japan
> [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED],jp.}FreeBSD.org
> http://www.imasy.org/~ume/
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: tcp hostcache and ip fastforward for review
Hi,
> On Sun, 09 Nov 2003 17:19:07 +0100
> Andre Oppermann <[EMAIL PROTECTED]> said:
oppermann> The patch is here (relative to -CURRENT as of 2003-11-09):
oppermann> http://www.nrg4u.com/freebsd/tcphostcache+ipfastforward-20031109.patch
It panics at boot around invoking rtsol(8):
Fatal trap 12: page fault while in kernel mode
fault virtual address = 0x80
fault code = supervisor write, page not present
instruction pointer = 0x8:0xc05b5278
stack pointer = 0x10:0xd7be0944
frame pointer = 0x10:0xd7be0998
code segment= base 0x0, limit 0xf, type 0x1b
= DPL 0, pres 1, def32 1, gran 1
processor eflags= interrupt enabled, resume, IOPL = 0
current process = 4912 (rtsol)
trap number = 12
panic: page fault
#0 doadump ()
at /usr/home/ume/cvs/freefall/current/src/sys/kern/kern_shutdown.c:240
240 dumping++;
(kgdb) bt
#0 doadump ()
at /usr/home/ume/cvs/freefall/current/src/sys/kern/kern_shutdown.c:240
#1 0xc04fad80 in boot (howto=256)
at /usr/home/ume/cvs/freefall/current/src/sys/kern/kern_shutdown.c:372
#2 0xc04fb168 in panic ()
at /usr/home/ume/cvs/freefall/current/src/sys/kern/kern_shutdown.c:550
#3 0xc0662316 in trap_fatal (frame=0xd7be0904, eva=0)
at /usr/home/ume/cvs/freefall/current/src/sys/i386/i386/trap.c:821
#4 0xc0661fb2 in trap_pfault (frame=0xd7be0904, usermode=0, eva=128)
at /usr/home/ume/cvs/freefall/current/src/sys/i386/i386/trap.c:735
#5 0xc0661b05 in trap (frame=
{tf_fs = -1068629992, tf_es = -675414000, tf_ds = -675414000, tf_edi =
-1010894932, tf_esi = -675411476, tf_ebp = -675411560, tf_isp = -675411664, tf_ebx =
0, tf_edx = -1010048384, tf_ecx = 0, tf_eax = 4, tf_trapno = 12, tf_err = 2, tf_eip =
-1067756936, tf_cs = 8, tf_eflags = 66118, tf_esp = -675411440, tf_ss = -675411320})
at /usr/home/ume/cvs/freefall/current/src/sys/i386/i386/trap.c:420
#6 0xc0652df8 in calltrap () at {standard input}:94
#7 0xc05b4b5b in in6_selectsrc (dstsock=0xd7be09ec, opts=0xd7be0a88,
mopts=0x0, ro=0x0, laddr=0xc3bef7ac, errorp=0xd7be0a84)
at /usr/home/ume/cvs/freefall/current/src/sys/netinet6/in6_src.c:242
#8 0xc05cda65 in rip6_output (m=0xc19a1000)
at /usr/home/ume/cvs/freefall/current/src/sys/netinet6/raw_ip6.c:426
#9 0xc05ce4ec in rip6_send (so=0xc3bdf660, flags=0, m=0xc19a1000, nam=0x0,
control=0x0, td=0xc3cbe280)
at /usr/home/ume/cvs/freefall/current/src/sys/netinet6/raw_ip6.c:742
#10 0xc053a62d in sosend (so=0xc3bdf660, addr=0xc39bbb20, uio=0xd7be0bf4,
top=0xc19a1000, control=0xc19a1100, flags=0, td=0xc3cbe280)
at /usr/home/ume/cvs/freefall/current/src/sys/kern/uipc_socket.c:715
#11 0xc053ef7c in kern_sendit (td=0xc3cbe280, s=3, mp=0xd7be0ca4, flags=0,
control=0x0)
---Type to continue, or q to quit---
at /usr/home/ume/cvs/freefall/current/src/sys/kern/uipc_syscalls.c:722
#12 0xc053ed9e in sendit (td=0x0, s=0, mp=0xd7be0ca4, flags=0)
at /usr/home/ume/cvs/freefall/current/src/sys/kern/uipc_syscalls.c:662
#13 0xc053f393 in sendmsg (td=0x0, uap=0xd7be0d10)
at /usr/home/ume/cvs/freefall/current/src/sys/kern/uipc_syscalls.c:900
#14 0xc06626a0 in syscall (frame=
{tf_fs = 47, tf_es = 47, tf_ds = 47, tf_edi = 5, tf_esi = 1, tf_ebp =
-1077940776, tf_isp = -675410572, tf_ebx = 134549504, tf_edx = 134545504, tf_ecx =
134545504, tf_eax = 28, tf_trapno = 12, tf_err = 2, tf_eip = 671923007, tf_cs = 31,
tf_eflags = 514, tf_esp = -1077940852, tf_ss = 47})
at /usr/home/ume/cvs/freefall/current/src/sys/i386/i386/trap.c:1010
#15 0xc0652e4d in Xint0x80_syscall () at {standard input}:136
---Can't read userspace from dump, or kernel process---
(kgdb) frame 7
#7 0xc05b4b5b in in6_selectsrc (dstsock=0xd7be09ec, opts=0xd7be0a88,
mopts=0x0, ro=0x0, laddr=0xc3bef7ac, errorp=0xd7be0a84)
at /usr/home/ume/cvs/freefall/current/src/sys/netinet6/in6_src.c:242
242 if ((*errorp = in6_selectif(dstsock, opts, mopts, ro, &ifp)) != 0)
(kgdb)
Sincerely,
--
Hajimu UMEMOTO @ Internet Mutual Aid Society Yokohama, Japan
[EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED],jp.}FreeBSD.org
http://www.imasy.org/~ume/
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: tcp hostcache and ip fastforward for review
Hi Andre, Your patch applies just fine for me now on Oct 10th current sources. Everything seems to be working fine on dual processor Dell 2500 with SMP kernel. This is a network backup machine. I don't see any problems, just as fast as always and seems to be solid so far, it has only been running a few hours. I ran some network backups to this server and ssh sessions out. Thanks Ken riker# sysctl -a net.inet.tcp.hostcache.list net.inet.tcp.hostcache.list: IP addressMTU SSTRESH RTT RTTVAR BANDWIDTH CWND SENDPIPE RECVPIPE HITS UPD EXP 209.123.219.10 00 14ms 9ms 1805600 6516 0043 3600 207.99.22.1900 17ms 13ms 109840065535 0043 600 - Original Message - From: "Andre Oppermann" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]>; <[EMAIL PROTECTED]> Cc: <[EMAIL PROTECTED]>; <[EMAIL PROTECTED]>; <[EMAIL PROTECTED]> Sent: Sunday, November 09, 2003 11:19 AM Subject: tcp hostcache and ip fastforward for review > Hello all, > > this patch contains three things (to be separated for committing): > > tcp_hostcache > > - removes protocol cloning from routing table (IPv4+6) > - removes rtentry pointer from inpcb and in6pcb ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: tcp hostcache and ip fastforward for review
Hi,
> On Sun, 09 Nov 2003 17:19:07 +0100
> Andre Oppermann <[EMAIL PROTECTED]> said:
oppermann> The patch is here (relative to -CURRENT as of 2003-11-09):
oppermann> http://www.nrg4u.com/freebsd/tcphostcache+ipfastforward-20031109.patch
The patch cannot be compiled:
cc -c -O -pipe -march=pentium3 -Wall -Wredundant-decls -Wnested-externs
-Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual
-fformat-extensions -std=c99 -g -nostdinc -I- -I.
-I/usr/home/ume/cvs/freefall/current/src/sys
-I/usr/home/ume/cvs/freefall/current/src/sys/contrib/dev/acpica
-I/usr/home/ume/cvs/freefall/current/src/sys/contrib/ipfilter
-I/usr/home/ume/cvs/freefall/current/src/sys/contrib/dev/ath
-I/usr/home/ume/cvs/freefall/current/src/sys/contrib/dev/ath/freebsd
-I/usr/home/ume/cvs/freefall/current/src/sys/contrib/ngatm -D_KERNEL -include
opt_global.h -fno-common -finline-limit=15000 -fno-strict-aliasing
-mno-align-long-strings -mpreferred-stack-boundary=2 -ffreestanding -Werror
/usr/home/ume/cvs/freefall/current/src/sys/netinet/ip_input.c
/usr/home/ume/cvs/freefall/current/src/sys/netinet/ip_input.c: In function
`ip_forward':
/usr/home/ume/cvs/freefall/current/src/sys/netinet/ip_input.c:1960: warning: implicit
declaration of function `ipsec_getpolicybyaddr'
/usr/home/ume/cvs/freefall/current/src/sys/netinet/ip_input.c:1963: warning:
assignment makes pointer from integer without a cast
*** Error code 1
There is no ipsec_getpolicybyaddr() for IPSEC. And, #ifdef is
slightly complex.
I don't tested it actually, yet.
--- sys/netinet/ip_input.c.orig Wed Nov 12 00:08:42 2003
+++ sys/netinet/ip_input.c Wed Nov 12 00:18:50 2003
@@ -1957,10 +1957,17 @@
int ipsechdr;
struct route *ro;
+#ifdef IPSEC
+ sp = ipsec4_getpolicybyaddr(mcopy,
+ IPSEC_DIR_OUTBOUND,
+ IP_FORWARDING,
+ &ipsecerror);
+#else
sp = ipsec_getpolicybyaddr(mcopy,
IPSEC_DIR_OUTBOUND,
IP_FORWARDING,
&ipsecerror);
+#endif
if (sp != NULL) {
/* count IPsec header size */
@@ -1995,13 +2002,11 @@
#else
KEY_FREESP(&sp);
#endif
- ipstat.ips_cantfrag++;
- break;
- } else
-#endif /*IPSEC || FAST_IPSEC*/
- destifp = ia->ia_ifp;
-#if defined(IPSEC) || defined(FAST_IPSEC)
+ } else
+ destifp = ia->ia_ifp;
}
+#else
+ destifp = ia->ia_ifp;
#endif /*IPSEC || FAST_IPSEC*/
ipstat.ips_cantfrag++;
break;
Sincerely,
--
Hajimu UMEMOTO @ Internet Mutual Aid Society Yokohama, Japan
[EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED],jp.}FreeBSD.org
http://www.imasy.org/~ume/
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: tcp hostcache and ip fastforward for review
Leo Bicknell wrote: > > In a message written on Mon, Nov 10, 2003 at 01:45:48PM -0600, Mike Silbersack wrote: > > > At the moment is visible via "sysctl -a net.inet.tcp.hostcache.list". > > > Syncache ain't visible via netstat either. So far you had to use > > > route get x.x.x.x to see the rtmetrics for a (host-)route. So I'm > > > sure whether netstat is the right place for it. But I can do that > > > in a second step. > > > > Ok, that should be good enough for now. > > I'm not going to say it's not good enough, but more than once the whole > "route get" thing has been quite inconveniant, so I'll put in a big vote > that both be available in easy to get table form from some command line > utility (netstat seems like a good place). I'll look into that when 5.2 is in code freeze. Can then put it in afterwards. -- Andre ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: tcp hostcache and ip fastforward for review
In a message written on Mon, Nov 10, 2003 at 01:45:48PM -0600, Mike Silbersack wrote: > > At the moment is visible via "sysctl -a net.inet.tcp.hostcache.list". > > Syncache ain't visible via netstat either. So far you had to use > > route get x.x.x.x to see the rtmetrics for a (host-)route. So I'm > > sure whether netstat is the right place for it. But I can do that > > in a second step. > > Ok, that should be good enough for now. I'm not going to say it's not good enough, but more than once the whole "route get" thing has been quite inconveniant, so I'll put in a big vote that both be available in easy to get table form from some command line utility (netstat seems like a good place). -- Leo Bicknell - [EMAIL PROTECTED] - CCIE 3440 PGP keys at http://www.ufp.org/~bicknell/ Read TMBG List - [EMAIL PROTECTED], www.tmbg.org pgp0.pgp Description: PGP signature
Re: tcp hostcache and ip fastforward for review
On Mon, 10 Nov 2003, Andre Oppermann wrote: > > - Ensures that a cached entry isn't added until the 3WHS is completed. > > > > This should help make synfloods with random source addresses less > > damaging. > > The cache will only be updated if the tcp connection is being closed. > All updates are done in tcp_drop. The T/TCP updates have to be done > inline during connection setup. I've converted all places which > updated the T/TCP rtmetrics in routing table with updates to the > hostcache. Good, that's exactly how it should work. > > Would it be possible to provide a way for netstat to view the host cache > > table? I think that it would be useful. > > At the moment is visible via "sysctl -a net.inet.tcp.hostcache.list". > Syncache ain't visible via netstat either. So far you had to use > route get x.x.x.x to see the rtmetrics for a (host-)route. So I'm > sure whether netstat is the right place for it. But I can do that > in a second step. Ok, that should be good enough for now. > The actually solves the problem. Let me explain in more detail. When > we get so many small packets per second the CPU will become pretty > saturated. Depending on how much data is sent it can go on for minutes > or hours. This code jumps in there and disconnects the within a second. > Of course someone can immediatly reconnect and do it again. But that > needs the 3WHS again and gives some delay. In the end this code is > like the ICMP rate limiter code. It there to migitate a problem to > manageable level, not to make it go away. Ok, so the problem is that the sockbuf chain keeps getting longer, causing the delay to grow as more fragments pile in... I see now. I drop my objection to it. Mike "Silby" Silbersack ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: tcp hostcache and ip fastforward for review
Hajimu UMEMOTO wrote: > > Hi, > > > On Sun, 09 Nov 2003 17:19:07 +0100 > > Andre Oppermann <[EMAIL PROTECTED]> said: > > oppermann> Hajimu-san, I'm looking especially for comments on whether my changes > oppermann> to IPv6 are correct wrt IPv6 concepts. (I hope they are). > > I don't see the patch in detail, yet, it seems your change will affect > KAME's development. You should ask [EMAIL PROTECTED] for review your > patch in detail before committing into FreeBSD. Ok, I've written an email [EMAIL PROTECTED] However there is not very much time for them to respond before 5.2 code freeze. I've taken care in my changes not to break IPv6 and to be only minimal intrusive. -- Andre ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: tcp hostcache and ip fastforward for review
Hi, > On Sun, 09 Nov 2003 17:19:07 +0100 > Andre Oppermann <[EMAIL PROTECTED]> said: oppermann> Hajimu-san, I'm looking especially for comments on whether my changes oppermann> to IPv6 are correct wrt IPv6 concepts. (I hope they are). I don't see the patch in detail, yet, it seems your change will affect KAME's development. You should ask [EMAIL PROTECTED] for review your patch in detail before committing into FreeBSD. Sincerely, -- Hajimu UMEMOTO @ Internet Mutual Aid Society Yokohama, Japan [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED],jp.}FreeBSD.org http://www.imasy.org/~ume/ ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: tcp hostcache and ip fastforward for review
On Nov 10, 2003, at 1:39 AM, Andre Oppermann wrote: Jonathan Mini wrote: All in all I don't think it is worth adding this complexity. I agree. This is actually a small value for TCP connections which are being used to forward messages, especially on gigabit links. Heavily-intensive web applications that are using small HTTP requests (pipelined inside a persistent connection) to update small manipulations of state are a good example of this. I wouldn't be surprised to see chatter between SQL servers follow similar patterns. Applications which use XML-based messaging often send several small packets per message, which is unfortunate. Do you think such applications manage to send 1000 packets per second with less than 256 bytes payload per packet? I think the network code would collect some data to form a larger packet (unless TCP_NODELAY set)? Traffic like that only happens when TCP_NODELAY is set. Otherwise, you get what you would expect. On the other hand, I'm used to looking at proxies, which are not the general case. This is why the limits are tunable, after all. =) Is there way you could monitor such connections and compile some statistics how many small packets per second are sent? I could adjust the patch to just report the fact instead of dropping the connection. Could do it for 4.9-R too, it's fairly easy. Alas, no. This is from anecdotal experience from our support staff at work. -- Jonathan Mini [EMAIL PROTECTED] http://www.freebsd.org ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: tcp hostcache and ip fastforward for review
Mike Silbersack wrote: > > On Sun, 9 Nov 2003, Andre Oppermann wrote: > > > Hello all, > > > > this patch contains three things (to be separated for committing): > > I don't have much time free in the next week, so I cannot do a complete > review. However, I just did a quick readthrough. > > > tcp_hostcache > > This looks good to me, I've been waiting for you to finish it for a long > time. You actually missed a point: > > - Ensures that a cached entry isn't added until the 3WHS is completed. > > This should help make synfloods with random source addresses less > damaging. The cache will only be updated if the tcp connection is being closed. All updates are done in tcp_drop. The T/TCP updates have to be done inline during connection setup. I've converted all places which updated the T/TCP rtmetrics in routing table with updates to the hostcache. > Would it be possible to provide a way for netstat to view the host cache > table? I think that it would be useful. At the moment is visible via "sysctl -a net.inet.tcp.hostcache.list". Syncache ain't visible via netstat either. So far you had to use route get x.x.x.x to see the rtmetrics for a (host-)route. So I'm sure whether netstat is the right place for it. But I can do that in a second step. > > ip_fastforward > > No comment, I didn't read through this part, and I'm not familiar with > the forwarding code. > > > tcp bug fixes and MSS DoS attack prevention > > Generally good, but: > > > - adds tcp_minmssoverload which disconnects a TCP session if > > it receives too many (1000) packets per second whose average > > segement size is lower than tcp_minmss > > - DoS attack 2: make MSS very low on local side of connection > > and send mny small packet to remote host. For every packet > > (eg. 2 bytes payload) a sowakeup is done to the listening > > process. Consumes a lot of CPU there. > > I don't think that your patch for this really solves anything. Anyone who > would write such a program could just as easily make it use concurrent > connections, have it auto-reconnect, and/or have it only send 900 packets > per second. I think that you should remove this section of the patch, but > leave a comment about this problem existing so that it will be thought > more about in the future. The actually solves the problem. Let me explain in more detail. When we get so many small packets per second the CPU will become pretty saturated. Depending on how much data is sent it can go on for minutes or hours. This code jumps in there and disconnects the within a second. Of course someone can immediatly reconnect and do it again. But that needs the 3WHS again and gives some delay. In the end this code is like the ICMP rate limiter code. It there to migitate a problem to manageable level, not to make it go away. > After the rest of the code is in, we can brainstorm on other possible > solutions... I think that Mini's idea of approaching it as an optimization > is the correct one. Ok, for brainstorming. For Mini's idea see my answer to him. -- Andre ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: tcp hostcache and ip fastforward for review
Jonathan Mini wrote: > > On Nov 9, 2003, at 2:47 PM, Andre Oppermann wrote: > > > Jonathan Mini wrote: > >> > >> On Nov 9, 2003, at 8:19 AM, Andre Oppermann wrote: > >> > >>> - DoS attack 2: make MSS very low on local side of connection > >>> and send mny small packet to remote host. For every packet > >>> (eg. 2 bytes payload) a sowakeup is done to the listening > >>> process. Consumes a lot of CPU there. > >>> > >> > >> This sounds as if it might be worthwhile to add a delay to > >> the TF_NODELAY case for receive processing as well. > > > > Unfortunatly it is not that easy. We can't just do that unconditionally > > to all connections. It would probably break or delay many things. You > > never know how much data is outstanding and whether it's just this > > packet with 2 bytes outstanding... > > This would be disastrous to the performance of interactive > sockets, however theoretically those connections have > NODELAY set. My above comment is a bit confusing: I meant the > "non TF_NODELAY" case, that is when Nagling is enabled. > > In this situation, you would be delay an sowakeup until > either a timeout or SO_RCVLOWAT-set value was reached. The normal > SO_RCVLOWAT case delays until SO_RCVTIMEO is reached. I suppose > the application could simulate this with a large SO_RCVLOWAT and a > small SO_RCVTIMEO, but I was wondering about the effects of such a > change as part of !TF_NODELAY. To do this we need another callout to do the eventual wakeup if no further packet arrive within whatever/HZ. In addition it probably would make FreeBSD look bad in network benchmarks since this causes the connection RTT to go up. All in all I don't think it is worth adding this complexity. > Sadly, there's this PSH bit in the TCP header that's completely > unreliable and could be used for scenarios like this. > > > As an application aware of this problematic you have currently two > > options: use accept filters (FreeBSD only) or set SO_RCVLOWAT to some > > higher value than the default 1 byte. Only the first one is workable > > if you don't know what and how much the clients send to you. Relying > > on the application to activate any such option to prevent this kind > > of DoS is unfortunatly whishful thinking. > > I was not suggesting that we use this to counter an attack, only asking > if it might be a worthwhile performance optimization to consider. > This is an unlikely case (many small packets sent to a non-interactive > application), so I can't see the improvement as being globally useful. No, I don't think it is a worthwhile opimization. If the application wants to do it, it can do so already via socket options. Normally an application needs such a delay feature to be specific to it's message types. Like with http accept filter. > > The code I've put in here simply caps off the extreme cases. It > > counts all packets and bytes in any given second and computes the > > average payload size per packet. If that is less than we have defined > > for minmss it will reset and drop the connection. However it will only > > start to compute the average if there are more than 1'000 packets per > > second on the same tcp connection. I've chosen this quite high value > > to never disconnect any ligitimate connection which just happens to > > send many small packets. In my tests I've seen telnet/ssh sending > > close to 100 small packets per second (some large copy-pasting and > > cat'ing of many small files). Probably 500 packets per second is a > > better cut-off value but I just want to be sure to never hit a false > > positive. > > This is actually a small value for TCP connections which are being > used to forward messages, especially on gigabit links. > Heavily-intensive > web applications that are using small HTTP requests (pipelined inside a > persistent connection) to update small manipulations of state are > a good example of this. I wouldn't be surprised to see chatter > between SQL servers follow similar patterns. Applications which > use XML-based messaging often send several small packets per message, > which is unfortunate. Do you think such applications manage to send 1000 packets per second with less than 256 bytes payload per packet? I think the network code would collect some data to form a larger packet (unless TCP_NODELAY set)? > On the other hand, I'm used to looking at proxies, which are not > the general case. This is why the limits are tunable, after all. =) Is there way you could monitor such connections and compile some statistics how many small packets per second are sent? I could adjust the patch to just report the fact instead of dropping the connection. Could do it for 4.9-R too, it's fairly easy. -- Andre ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: tcp hostcache and ip fastforward for review
On Sun, 9 Nov 2003, Andre Oppermann wrote: > Hello all, > > this patch contains three things (to be separated for committing): I don't have much time free in the next week, so I cannot do a complete review. However, I just did a quick readthrough. > tcp_hostcache This looks good to me, I've been waiting for you to finish it for a long time. You actually missed a point: - Ensures that a cached entry isn't added until the 3WHS is completed. This should help make synfloods with random source addresses less damaging. Would it be possible to provide a way for netstat to view the host cache table? I think that it would be useful. > ip_fastforward No comment, I didn't read through this part, and I'm not familiar with the forwarding code. > tcp bug fixes and MSS DoS attack prevention Generally good, but: > - adds tcp_minmssoverload which disconnects a TCP session if > it receives too many (1000) packets per second whose average > segement size is lower than tcp_minmss > - DoS attack 2: make MSS very low on local side of connection > and send mny small packet to remote host. For every packet > (eg. 2 bytes payload) a sowakeup is done to the listening > process. Consumes a lot of CPU there. I don't think that your patch for this really solves anything. Anyone who would write such a program could just as easily make it use concurrent connections, have it auto-reconnect, and/or have it only send 900 packets per second. I think that you should remove this section of the patch, but leave a comment about this problem existing so that it will be thought more about in the future. After the rest of the code is in, we can brainstorm on other possible solutions... I think that Mini's idea of approaching it as an optimization is the correct one. Mike "Silby" Silbersack ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: tcp hostcache and ip fastforward for review
On Nov 9, 2003, at 2:47 PM, Andre Oppermann wrote: Jonathan Mini wrote: On Nov 9, 2003, at 8:19 AM, Andre Oppermann wrote: - DoS attack 2: make MSS very low on local side of connection and send mny small packet to remote host. For every packet (eg. 2 bytes payload) a sowakeup is done to the listening process. Consumes a lot of CPU there. This sounds as if it might be worthwhile to add a delay to the TF_NODELAY case for receive processing as well. Unfortunatly it is not that easy. We can't just do that unconditionally to all connections. It would probably break or delay many things. You never know how much data is outstanding and whether it's just this packet with 2 bytes outstanding... This would be disastrous to the performance of interactive sockets, however theoretically those connections have NODELAY set. My above comment is a bit confusing: I meant the "non TF_NODELAY" case, that is when Nagling is enabled. In this situation, you would be delay an sowakeup until either a timeout or SO_RCVLOWAT-set value was reached. The normal SO_RCVLOWAT case delays until SO_RCVTIMEO is reached. I suppose the application could simulate this with a large SO_RCVLOWAT and a small SO_RCVTIMEO, but I was wondering about the effects of such a change as part of !TF_NODELAY. Sadly, there's this PSH bit in the TCP header that's completely unreliable and could be used for scenarios like this. As an application aware of this problematic you have currently two options: use accept filters (FreeBSD only) or set SO_RCVLOWAT to some higher value than the default 1 byte. Only the first one is workable if you don't know what and how much the clients send to you. Relying on the application to activate any such option to prevent this kind of DoS is unfortunatly whishful thinking. I was not suggesting that we use this to counter an attack, only asking if it might be a worthwhile performance optimization to consider. This is an unlikely case (many small packets sent to a non-interactive application), so I can't see the improvement as being globally useful. The code I've put in here simply caps off the extreme cases. It counts all packets and bytes in any given second and computes the average payload size per packet. If that is less than we have defined for minmss it will reset and drop the connection. However it will only start to compute the average if there are more than 1'000 packets per second on the same tcp connection. I've chosen this quite high value to never disconnect any ligitimate connection which just happens to send many small packets. In my tests I've seen telnet/ssh sending close to 100 small packets per second (some large copy-pasting and cat'ing of many small files). Probably 500 packets per second is a better cut-off value but I just want to be sure to never hit a false positive. This is actually a small value for TCP connections which are being used to forward messages, especially on gigabit links. Heavily-intensive web applications that are using small HTTP requests (pipelined inside a persistent connection) to update small manipulations of state are a good example of this. I wouldn't be surprised to see chatter between SQL servers follow similar patterns. Applications which use XML-based messaging often send several small packets per message, which is unfortunate. On the other hand, I'm used to looking at proxies, which are not the general case. This is why the limits are tunable, after all. =) -- Jonathan Mini [EMAIL PROTECTED] http://www.freebsd.org ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: tcp hostcache and ip fastforward for review
Jonathan Mini wrote: > > On Nov 9, 2003, at 8:19 AM, Andre Oppermann wrote: > > > - DoS attack 2: make MSS very low on local side of connection > > and send mny small packet to remote host. For every packet > > (eg. 2 bytes payload) a sowakeup is done to the listening > > process. Consumes a lot of CPU there. > > > > This sounds as if it might be worthwhile to add a delay to > the TF_NODELAY case for receive processing as well. Unfortunatly it is not that easy. We can't just do that unconditionally to all connections. It would probably break or delay many things. You never know how much data is outstanding and whether it's just this packet with 2 bytes outstanding... As an application aware of this problematic you have currently two options: use accept filters (FreeBSD only) or set SO_RCVLOWAT to some higher value than the default 1 byte. Only the first one is workable if you don't know what and how much the clients send to you. Relying on the application to activate any such option to prevent this kind of DoS is unfortunatly whishful thinking. The code I've put in here simply caps off the extreme cases. It counts all packets and bytes in any given second and computes the average payload size per packet. If that is less than we have defined for minmss it will reset and drop the connection. However it will only start to compute the average if there are more than 1'000 packets per second on the same tcp connection. I've chosen this quite high value to never disconnect any ligitimate connection which just happens to send many small packets. In my tests I've seen telnet/ssh sending close to 100 small packets per second (some large copy-pasting and cat'ing of many small files). Probably 500 packets per second is a better cut-off value but I just want to be sure to never hit a false positive. -- Andre ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: tcp hostcache and ip fastforward for review
On Nov 9, 2003, at 8:19 AM, Andre Oppermann wrote: - DoS attack 2: make MSS very low on local side of connection and send mny small packet to remote host. For every packet (eg. 2 bytes payload) a sowakeup is done to the listening process. Consumes a lot of CPU there. This sounds as if it might be worthwhile to add a delay to the TF_NODELAY case for receive processing as well. -- Jonathan Mini [EMAIL PROTECTED] http://www.freebsd.org ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
tcp hostcache and ip fastforward for review
Hello all, this patch contains three things (to be separated for committing): tcp_hostcache - removes protocol cloning from routing table (IPv4+6) - removes rtentry pointer from inpcb and in6pcb - removes ip route cache in ip_input.c (locking much easier) - removes most (tcp specific) metrics from rtentry metrics - adds a hostcache table which carries the metrics for tcp - works transparently for IPv4 and IPv6 - is designed for concurrent access in SMP environments - significant reduction of routing table size (no cloning anymore) - eases many routing table locking situations in ip/tcp code ip_fastforward - removes ip_flow forwarding code - adds full direct process-to-completion IPv4 forwarding code - handles ip fragmentation incl. hw support (ip_flow did not) - supports ipfw and ipfilter (ip_flow did not) - supports divert and ipfw fwd (ip_flow did not) - drops anything it can't handle back to normal ip_input tcp bug fixes and MSS DoS attack prevention - fixes wrong goto in tcp_input.c which sends two RST packets instead of one - adds tcp_minmss sysctl which limits the lowest MSS we accept during TCP setup and path MTU discovery - adds tcp_minmssoverload which disconnects a TCP session if it receives too many (1000) packets per second whose average segement size is lower than tcp_minmss - DoS attack 1: send very low MSS in syn to remote host, request large data stream (file) and let other host produce mny small packets which consumes a lot of CPU - DoS attack 2: make MSS very low on local side of connection and send mny small packet to remote host. For every packet (eg. 2 bytes payload) a sowakeup is done to the listening process. Consumes a lot of CPU there. I'm looking for any comments, testing and bug reports (if any ;-). Hajimu-san, I'm looking especially for comments on whether my changes to IPv6 are correct wrt IPv6 concepts. (I hope they are). Hopefully these things can make it into -CURRENT before 5.2 release. Sam Leffler has indicated he is willing to commit it when there are no objections to the implementation and the code. I am fully committed to fix any bugs that might come up after it's in the tree. I am running my machines with these changes for a couple of weeks now without any problems. The attached patch obviously doesn't have that much exposure because I've had to update it all the time to track Sam's locking changes and UME's IPv6 updates. The patch is here (relative to -CURRENT as of 2003-11-09): http://www.nrg4u.com/freebsd/tcphostcache+ipfastforward-20031109.patch I'm grateful for everyone who tries out the patch and reports their success and/or other findings. -- Andre ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
