Peter Schow wrote: > On Fri, Nov 27, 2009 at 07:57:34PM -0800, Michael Eager wrote: >> Hi -- >> >> I'm running OpenSolaris 2009.06 on a machine with >> a 1 Gigabit Ethernet network connection over a local >> network. Transferring files over the network from >> another (Linux) system with a similar connection. >> The Linux system has mtu=9000. >> >> I was trying to set the MTU of the OpenSolaris >> network interface to 9000, by using >> >> # dladm set-linkprop -p mtu=9000 rge0 >> >> This gets an error message saying that this is not >> permitted. Trying with "ifconfig rge0 mtu 9000" >> gets an invalid argument message. >> >> Is there any way that I can have the Solaris >> box support jumbo frames? Is this a function of >> the network interface or internal to the software >> stack? > > > See if this helps: > > http://opensolaris.org/jive/thread.jspa?messageID=20675 > > Looks like the maximum MTU on rge is 7000.
Thanks! That helps, at least, partially. I can set the MTU to any value up to 7000 and it appears to work. When I set the MTU to 7000, or something other than 1500, the network connection appears OK on the OpenSolaris system. I can access the internet and open web pages. I am able to ssh from the OpenSolaris system to the Linux system. But this causes a strange problem: I cannot connect to the OpenSolaris system using SSH. Ssh appears to establish a connection but sshd on OpenSolaris fails to respond when during key negotiation. (Diagnostics from ssh below.) A similar problem happens trying to connect to a VNC server on the OpenSolaris system. VNC appears to connect, and displays a window, but the client remains black. Both problems disappear when I reset the MTU to 1500. If I have previously established a connection (either ssh or vnc) then changing the MTU to 7000 doesn't break the connection. Diagnostics from ssh are the same up to the point where the OpenSolaris system fails to respond: OpenSSH_5.1p1, OpenSSL 0.9.8g 19 Oct 2007 debug1: Reading configuration data /home/eager/.ssh/config debug1: Reading configuration data /etc/ssh/ssh_config debug1: Applying options for * debug2: ssh_connect: needpriv 0 debug1: Connecting to maple [192.168.20.14] port 22. debug1: Connection established. debug1: identity file /home/eager/.ssh/identity type -1 debug2: key_type_from_name: unknown key type '-----BEGIN' debug2: key_type_from_name: unknown key type '-----END' debug1: identity file /home/eager/.ssh/id_rsa type 1 debug2: key_type_from_name: unknown key type '-----BEGIN' debug2: key_type_from_name: unknown key type '-----END' debug1: identity file /home/eager/.ssh/id_dsa type 2 debug1: Remote protocol version 2.0, remote software version Sun_SSH_1.3 debug1: no match: Sun_SSH_1.3 debug1: Enabling compatibility mode for protocol 2.0 debug1: Local version string SSH-2.0-OpenSSH_5.1 debug2: fd 3 setting O_NONBLOCK debug1: SSH2_MSG_KEXINIT sent <with MTU=7000, the debug trace stops here> debug1: SSH2_MSG_KEXINIT received debug2: kex_parse_kexinit: diffie-hellman-group-exchange-sha256,diffie-hellman-group-exchange-sha1,diffie-hellman-grou p14-sha1,diffie-hellman-group1-sha1 debug2: kex_parse_kexinit: ssh-rsa,ssh-dss debug2: kex_parse_kexinit: aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,arcfour128,arcfour256,arcfour,aes192-cbc,aes25 6-cbc,rijndael-cbc at lysator.liu.se,aes128-ctr,aes192-ctr,aes256-ctr debug2: kex_parse_kexinit: aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,arcfour128,arcfour256,arcfour,aes192-cbc,aes25 6-cbc,rijndael-cbc at lysator.liu.se,aes128-ctr,aes192-ctr,aes256-ctr debug2: kex_parse_kexinit: hmac-md5,hmac-sha1,umac-64 at openssh.com,hmac-ripemd160,hmac-ripemd160 at openssh.com,hmac-sha1- 96,hmac-md5-96 debug2: kex_parse_kexinit: hmac-md5,hmac-sha1,umac-64 at openssh.com,hmac-ripemd160,hmac-ripemd160 at openssh.com,hmac-sha1- 96,hmac-md5-96 debug2: kex_parse_kexinit: none,zlib at openssh.com,zlib debug2: kex_parse_kexinit: none,zlib at openssh.com,zlib . . . Any help with this very unexpected fallout of setting the MTU? -- Michael Eager eager at eagercon.com 1960 Park Blvd., Palo Alto, CA 94306 650-325-8077
