Re: strange TCP issue on RELENG_7
Yes, he has the same issue. -Kip On Sat, Aug 23, 2008 at 10:59 PM, Julian Elischer [EMAIL PROTECTED] wrote: Kip Macy wrote: On Sat, Aug 23, 2008 at 10:52 PM, Julian Elischer [EMAIL PROTECTED] wrote: Mike Tancsa wrote: At 10:16 PM 8/23/2008, Kip Macy wrote: Can you help me out a bit with your workload? tcp_offload_connect(...) needs to determine which interface an address corresponds to see if that interface supports TCP offload. The code does the exact same thing as ip_output does except it doesn't have the inpcb locked (which isn't used as part of the route lookup). This is the only RELENG_7 box that I have where it routes tcp packets asymmetrically, so that sounds like it might be the portion that is badly interacting. The server has just one default gateway, which is out em0, but clients all over the net will connect to IP addresses aliased on lo0 and to the one IP on em1. But all connections exit out em0 other than connected routes of course. ---Mike Julian has worked in this code most recently, maybe he has some idea what is going on. huh? wha? I haven't been following this thread.. what's up? Julian - see previous e-mails, the arp cache gets messed up as a result of calling rtalloc in tcp_offload.c - which is done to determine which interface will be used for connection. Any thoughts on why it may end up with dozens of bogus entries? -Kip has anyone tried the same scenario on -current? ___ 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: strange TCP issue on RELENG_7
Kip Macy wrote: Yes, he has the same issue. -Kip On Sat, Aug 23, 2008 at 10:59 PM, Julian Elischer [EMAIL PROTECTED] wrote: Kip Macy wrote: On Sat, Aug 23, 2008 at 10:52 PM, Julian Elischer [EMAIL PROTECTED] wrote: Mike Tancsa wrote: At 10:16 PM 8/23/2008, Kip Macy wrote: Can you help me out a bit with your workload? tcp_offload_connect(...) needs to determine which interface an address corresponds to see if that interface supports TCP offload. The code does the exact same thing as ip_output does except it doesn't have the inpcb locked (which isn't used as part of the route lookup). This is the only RELENG_7 box that I have where it routes tcp packets asymmetrically, so that sounds like it might be the portion that is badly interacting. The server has just one default gateway, which is out em0, but clients all over the net will connect to IP addresses aliased on lo0 and to the one IP on em1. But all connections exit out em0 other than connected routes of course. ---Mike Julian has worked in this code most recently, maybe he has some idea what is going on. huh? wha? I haven't been following this thread.. what's up? Julian - see previous e-mails, the arp cache gets messed up as a result of calling rtalloc in tcp_offload.c - which is done to determine which interface will be used for connection. Any thoughts on why it may end up with dozens of bogus entries? -Kip has anyone tried the same scenario on -current? ok so it might be related to the MRT code... I assume he only has one Routing table.. Theoretically it shoudl work the same as before if N==1 but I can imagine a case where it didn't. especially if arp and interffaces are involved.. Mike, can you give me a repro example? ___ 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]
Code review request
I've been shepherding this patch in my p4 tree for a long time. It
removes the obsolete support for other systems in if_spppsubr.c. Is
there a reason I shouldn't commit this?
Warner
Index: if_spppsubr.c
===
--- if_spppsubr.c (revision 182085)
+++ if_spppsubr.c (working copy)
@@ -23,38 +23,22 @@
#include sys/param.h
-#if defined(__FreeBSD__) __FreeBSD__ = 3
#include opt_inet.h
#include opt_inet6.h
#include opt_ipx.h
-#endif
-#ifdef NetBSD1_3
-# if NetBSD1_3 6
-# include opt_inet.h
-# include opt_inet6.h
-# include opt_iso.h
-# endif
-#endif
-
#include sys/systm.h
#include sys/kernel.h
#include sys/module.h
#include sys/sockio.h
#include sys/socket.h
#include sys/syslog.h
-#if defined(__FreeBSD__) __FreeBSD__ = 3
#include sys/random.h
-#endif
#include sys/malloc.h
#include sys/mbuf.h
#include sys/vimage.h
-#if defined (__OpenBSD__)
-#include sys/md5k.h
-#else
#include sys/md5.h
-#endif
#include net/if.h
#include net/netisr.h
@@ -65,10 +49,6 @@
#include netinet/ip.h
#include net/slcompress.h
-#if defined (__NetBSD__) || defined (__OpenBSD__)
-#include machine/cpu.h /* XXX for softnet */
-#endif
-
#include machine/stdarg.h
#include netinet/in_var.h
@@ -82,11 +62,7 @@
#include netinet6/scope6_var.h
#endif
-#if defined (__FreeBSD__) || defined (__OpenBSD__)
-# include netinet/if_ether.h
-#else
-# include net/ethertypes.h
-#endif
+#include netinet/if_ether.h
#ifdef IPX
#include netipx/ipx.h
@@ -95,12 +71,7 @@
#include net/if_sppp.h
-#if defined(__FreeBSD__) __FreeBSD__ = 3
-# define IOCTL_CMD_T u_long
-#else
-# define IOCTL_CMD_T int
-#endif
-
+#define IOCTL_CMD_Tu_long
#define MAXALIVECNT 3 /* max. alive packets */
/*
@@ -261,13 +232,8 @@
void(*scr)(struct sppp *sp);
};
-#if defined(__FreeBSD__) __FreeBSD__ = 3 __FreeBSD_version 501113
-#defineSPP_FMT %s%d:
-#defineSPP_ARGS(ifp) (ifp)-if_name, (ifp)-if_unit
-#else
#defineSPP_FMT %s:
#defineSPP_ARGS(ifp) (ifp)-if_xname
-#endif
#define SPPP_LOCK(sp) \
do { \
@@ -1422,11 +1388,7 @@
++sp-pp_loopcnt;
/* Generate new local sequence number */
-#if defined(__FreeBSD__) __FreeBSD__ = 3
sp-pp_seq[IDX_LCP] = random();
-#else
- sp-pp_seq[IDX_LCP] ^= time.tv_sec ^ time.tv_usec;
-#endif
break;
}
sp-pp_loopcnt = 0;
@@ -2671,11 +2633,7 @@
if (magic == ~sp-lcp.magic) {
if (debug)
log(-1, magic glitch );
-#if defined(__FreeBSD__) __FreeBSD__ = 3
sp-lcp.magic = random();
-#else
- sp-lcp.magic = time.tv_sec +
time.tv_usec;
-#endif
} else {
sp-lcp.magic = magic;
if (debug)
@@ -2856,11 +2814,7 @@
if (sp-lcp.opts (1 LCP_OPT_MAGIC)) {
if (! sp-lcp.magic)
-#if defined(__FreeBSD__) __FreeBSD__ = 3
sp-lcp.magic = random();
-#else
- sp-lcp.magic = time.tv_sec + time.tv_usec;
-#endif
opt[i++] = LCP_OPT_MAGIC;
opt[i++] = 6;
opt[i++] = sp-lcp.magic 24;
@@ -4383,15 +4337,7 @@
/* Compute random challenge. */
ch = (u_long *)sp-myauth.challenge;
-#if defined(__FreeBSD__) __FreeBSD__ = 3
read_random(seed, sizeof seed);
-#else
- {
- struct timeval tv;
- microtime(tv);
- seed = tv.tv_sec ^ tv.tv_usec;
- }
-#endif
ch[0] = seed ^ random();
ch[1] = seed ^ random();
ch[2] = seed ^ random();
@@ -4900,17 +4846,7 @@
* aliases don't make any sense on a p2p link anyway.
*/
si = 0;
-#if defined(__FreeBSD__) __FreeBSD__ = 3
TAILQ_FOREACH(ifa, ifp-if_addrhead, ifa_link)
-#elif defined(__NetBSD__) || defined (__OpenBSD__)
- for (ifa = TAILQ_FIRST(ifp-if_addrlist);
-ifa;
-ifa = TAILQ_NEXT(ifa, ifa_list))
-#else
- for (ifa = ifp-if_addrlist;
-ifa;
-ifa = ifa-ifa_next)
-#endif
if (ifa-ifa_addr-sa_family == AF_INET) {
si = (struct sockaddr_in *)ifa-ifa_addr;
sm = (struct sockaddr_in *)ifa-ifa_netmask;
@@ -4949,17 +4885,7 @@
* aliases don't make any sense on a p2p link anyway.
*/
si = 0;
-#if defined(__FreeBSD__) __FreeBSD__ = 3
TAILQ_FOREACH(ifa, ifp-if_addrhead, ifa_link)
-#elif defined(__NetBSD__) || defined (__OpenBSD__)
- for (ifa = TAILQ_FIRST(ifp-if_addrlist);
-ifa;
-
Re: strange TCP issue on RELENG_7
At 02:18 AM 8/24/2008, Julian Elischer wrote: ok so it might be related to the MRT code... I assume he only has one Routing table.. Yes, just one routing table Theoretically it shoudl work the same as before if N==1 but I can imagine a case where it didn't. especially if arp and interffaces are involved.. Mike, can you give me a repro example? I am not sure how, but it happens on this machine within seconds of all its applications starting up. I am speculating it has to do with the fact the machine has multiple public interfaces as well as IPs aliased to lo0 so that packets will come in em1 destined for em1 and lo0, but will always go out em0 ? The same for the kernel from HEAD shows the same behaviour. The problem started with the tcp offload code http://lists.freebsd.org/pipermail/freebsd-stable/2008-August/044468.html has more details ---Mike ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to [EMAIL PROTECTED]
[CFT/R] IPv4 source address selection
Hi, I have a patch, that was inspired by work from Y!, to do porper IPv4 source address selection for unbound sockets (with multi-IP jails). You can temporary find it here: http://people.freebsd.org/~bz/20080823-01-in_pcbladdr.diff People running my latest jail patches have been ``testing'' this without really knowing the last weeks. In case you wonder why, in the jail case, I loop over the ifa first before simply falling back to the primary jail IP (which is the only jail IP as in HEAD) -- this is because with the upcoming jail patches I have to check if any of possibly lots of IPs match any IP on an interface and only if none matches I have to fall back to the 'primary' jail IP. So the code has been prepared for upcoming changes already. Feel free to test it and report problems or unexpected behavior. Unless someone is going to cry it'll hit HEAD in a few days. /bz PS: in case you review this properly (not only glance at it or test it) let me know so I can punish you in the Reviewed by: line;-) -- 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: Code review request
M. Warner Losh wrote: I've been shepherding this patch in my p4 tree for a long time. It removes the obsolete support for other systems in if_spppsubr.c. Is there a reason I shouldn't commit this? Looks fine to me. ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Code review request
M. Warner Losh wrote: I've been shepherding this patch in my p4 tree for a long time. It removes the obsolete support for other systems in if_spppsubr.c. Is there a reason I shouldn't commit this? It was there to ease the keeping code in sync with other systems. Please ask Joerg Wunsch before removal. rik Warner ___ 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: [CFT/R] IPv4 source address selection
Bjoern A. Zeeb wrote: Hi, I have a patch, that was inspired by work from Y!, to do porper IPv4 source address selection for unbound sockets (with multi-IP jails). Hi, This kinda overlaps with some other ideas I'd like to see go in. It looks good and if it's already been tested, it should probably go in anyway as it disentangles the logic and puts it in a separate function. I'm thinking we may wish to use criteria other than interface or jailed socket to select source address. I should point out though that we picked some stuff up from KAME to do source address selection but it's not in the IPv4 stack. 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: Code review request
In message: [EMAIL PROTECTED] Roman Kurakin [EMAIL PROTECTED] writes: : M. Warner Losh wrote: : I've been shepherding this patch in my p4 tree for a long time. It : removes the obsolete support for other systems in if_spppsubr.c. Is : there a reason I shouldn't commit this? : : It was there to ease the keeping code in sync with other systems. : Please ask Joerg Wunsch before removal. Yea, I knew that history. But there's been a lot of hacking on this file, and the ifdef's are for other systems that were contemporaneous with FreeBSD 3.0, but nothing newer. Plus the FreeBSDisms that are newer haven't been ifdef'd. Warner ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to [EMAIL PROTECTED]
