On Sunday 29 October 2006 15:10, Herbert Xu wrote:

On Sun, Oct 29, 2006 at 01:55:56PM +0100, Denis Vlasenko wrote:

quoted

With "echo 1 >/proc/sys/kernel/panic_on_oops" I've got
what you're requested. See screenshot:

http://busybox.net/~vda/gso_panic/forcedeth_gso_panic2.jpg

Thanks!

Please let me know if this patch fixes it:

[NET]: Fix segmentation of linear packets

Okay, will test now.

The fact that you're triggering this bug at all means that
something else has gone wrong.  First of all your picture
shows a device setting of "lo".  This does not tally with
the fact that the BUG was triggered by ssh.  Do you have
any idea why this is the case? Do you have any netfilter
rules that might cause this?

Yes, I have netfilter rules which redirect all outgoing
port 22 connections to local port 2222. I run tcpserver
on 2222 which spawns hose for each connection.

All this ugliness is required to get ssh working across
buggy D-Link router. It chokes on nagle-disabled sessions,
I think.

The rules:

# iptables -t nat -N redir22
# iptables -t nat -A redir22 -d 192.168.1.111 -j RETURN
# iptables -t nat -A redir22 -d 127.0.0.1 -j RETURN
# iptables -t nat -A redir22 --match owner --uid-owner daemon -j RETURN
# iptables -t nat -A redir22 -p tcp -j REDIRECT --to 2222
# iptables -t nat -A OUTPUT -p tcp --dport 22 -j redir22

---FILTER--
Chain INPUT (policy ACCEPT 20 packets, 1360 bytes)
Chain FORWARD (policy ACCEPT 0 packets, 0 bytes)
Chain OUTPUT (policy ACCEPT 2 packets, 100 bytes)
---NAT-----
Chain PREROUTING (policy ACCEPT 0 packets, 0 bytes)
Chain POSTROUTING (policy ACCEPT 1 packets, 60 bytes)
Chain OUTPUT (policy ACCEPT 1 packets, 60 bytes)
       0        0 redir22    tcp  --  *      *       0.0.0.0/0            0.0.0.0/0           tcp dpt:22
Chain redir22 (1 references)
       0        0 RETURN     all  --  *      *       0.0.0.0/0            192.168.1.111
       0        0 RETURN     all  --  *      *       0.0.0.0/0            127.0.0.1
       0        0 RETURN     all  --  *      *       0.0.0.0/0            0.0.0.0/0           OWNER UID match 50
       0        0 REDIRECT   tcp  --  *      *       0.0.0.0/0            0.0.0.0/0           redir ports 2222
---MANGLE--
Chain PREROUTING (policy ACCEPT 2 packets, 100 bytes)
Chain INPUT (policy ACCEPT 2 packets, 100 bytes)
Chain FORWARD (policy ACCEPT 0 packets, 0 bytes)
Chain OUTPUT (policy ACCEPT 2 packets, 100 bytes)
Chain POSTROUTING (policy ACCEPT 2 packets, 100 bytes)

On port 2222 I have the following running:

run:
====
ip=0.0.0.0
port=2222
user=daemon
maxconn=100
# envuidgid $user tcpserver -U:
# run tcpserver as $user
exec \
env - \
softlimit \
envuidgid $user \
tcpserver \
    -U \
    -v -R -H -l 0 -c $maxconn \
    $ip $port \
./startproxy22

startproxy22
============
targetip="$TCPORIGDSTIP"
targetport=22
# Loop prevention
if test "$TCPLOCALIP" = "$targetip"; then
    if test "$TCPLOCALPORT" = "$targetport"; then
        env >loop.detected
        exit 0
    fi
fi
# netcat rulez... however hose of netpipes fame
# is still better because --netslave properly closes
# connection on input EOF.
exec env - hose "$targetip" "$targetport" --netslave

If it is indeed lo, could you please check the ethtool -k
setting on it? Also what is the ethtool -k setting on the
interface where you expect ssh to go out?

# ethtool -k lo
Offload parameters for lo:
Cannot get device rx csum settings: Operation not supported
Cannot get device tx csum settings: Operation not supported
Cannot get device scatter-gather settings: Operation not supported
rx-checksumming: off
tx-checksumming: off
scatter-gather: off
tcp segmentation offload: off
--
vda