strange TCP issue on RELENG_7

[Kip Macy]

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).

Julian has worked in this code most recently, maybe he has some idea
what is going on.

-Kip


On Fri, Aug 22, 2008 at 12:22 PM, Mike Tancsa <mike at sentex.net> wrote:
> At 03:12 PM 8/22/2008, Bjoern A. Zeeb wrote:
>
>> can you make sure you have this?
>>
>> http://svn.freebsd.org/changeset/base/181596
>
> Hi,
> I do. I am running a GENERIC kernel but with inet6 disabled from yesterday
>
> 7.0-STABLE #0: Thu Aug 21 10:27:04 EDT 2008
>
> and with the patch below as TOE seems to be broken for my workload
>
>
> # diff -u sys/netinet/tcp_offload.c sys/netinet/tcp_offload.c.disable
> --- sys/netinet/tcp_offload.c   2008-08-01 13:47:27.000000000 -0400
> +++ sys/netinet/tcp_offload.c.disable   2008-08-22 15:16:50.000000000 -0400
> @@ -58,6 +58,8 @@
>        struct rtentry *rt;
>        int error;
>
> +       return (EINVAL);
> +
>        /*
>         * Look up the route used for the connection to
>         * determine if it uses an interface capable of
>
> I can try changing to ipfw and see if that makes a difference ? But the RST
> doesnt sound like a pf issue no ? I would have thought it would just
> blackhole the packet.
>
>        ---Mike
> _______________________________________________
> freebsd-net at freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-net
> To unsubscribe, send any mail to "freebsd-net-unsubscribe at freebsd.org"
>