Re: [OpenIndiana-discuss] Installation on HD = 2TB
On 02/ 2/13 04:47 AM, Jim Klimov wrote: Well, I'm still puzzled why OI installer and/or gparted won't show you any info about the drive This message is what he sent me a while ago: Jan 29 05:07:08 openindianadisk has 3907029168 blocks, which is too large for a 32-bit kernel ___ OpenIndiana-discuss mailing list OpenIndiana-discuss@openindiana.org http://openindiana.org/mailman/listinfo/openindiana-discuss
Re: [OpenIndiana-discuss] Auto snapshots
From: Edward Ned Harvey (openindiana) [mailto:openindi...@nedharvey.com] In 151a5, I had to fiddle with password before time-slider GUI config worked. But the present release is 151a7, so maybe that's a resolved issue now. Either way, the workaround was trivial, so I would say you can safely call the issue resolved. Yesterday, I built a 151a5 server and upgraded to 151a7. The bug is still present. A few months ago, I did file a bug report, so eventually I'm sure it'll be resolved. But like I said, the workaround is trivial, so, ... whatever. ___ OpenIndiana-discuss mailing list OpenIndiana-discuss@openindiana.org http://openindiana.org/mailman/listinfo/openindiana-discuss
Re: [OpenIndiana-discuss] Installation on HD = 2TB
On 2013-02-02 10:59, Udo Grabowski (IMK) wrote: On 02/ 2/13 04:47 AM, Jim Klimov wrote: Well, I'm still puzzled why OI installer and/or gparted won't show you any info about the drive This message is what he sent me a while ago: Jan 29 05:07:08 openindianadisk has 3907029168 blocks, which is too large for a 32-bit kernel Hm... makes sense... and there were discussions in the past on how to try and enforce a 64-bit kernel/userspace for the installer. Should in fact happen automatically (with $ISADIR in GRUB menu) but may fail due to misdetection on some hardware and other circumstances. Namely - did not fail for me when I was using an OI livecd to add a 3Tb HDD to a pool of an older (SXCE) server which did not fully see the disk natively - but agreed to use the GPT partitioning which I imposed with OI. I believe, the trick is to edit the GRUB menu during boot (press e) and modify the kernel and module lines to replace $ISADIR with explicit amd64, then press b to load this configuration. If this workaround is needed after installation, it may IMHO be regarded as a bug, but easily mended by editing the GRUB menu file in /rpool/boot/grub/menu.lst in a similar fashion (probably best is to clone the existing entries, to leave ones with autodetection for reference and to use ones with explicit 64-bitness). HTH, ///Jim Klimov ___ OpenIndiana-discuss mailing list OpenIndiana-discuss@openindiana.org http://openindiana.org/mailman/listinfo/openindiana-discuss
[OpenIndiana-discuss] weird packet garbling problem
I am having a really hard time coming up with a plausible explanation for this, other than some kind of kernel bug with openindiana... I have two systems in the office, Dell PowerEdge SC 1435 (Embedded Broadcom 5721 NIC) and Dell PowerEdge 2950 (Embedded Broadcom 5708 NIC), both running OI 151a5 or newer. Inside the office, everything works fine. But when I go home and VPN into the office, I ssh or vnc to these two boxes, and I get packet garbling and retransmissions and dropped connections, but *only* on these two machines, and *only* from the vpn connection, and *only* for certain specific types of traffic. Here's an example: I'm on an ssh prompt. I can type in commands all day and night, it always works fine when I'm typing. (One character at a time, typing via keyboard, I can hold down a key and completely fill the screen, 4320 keystrokes no problem.) But I'm following a procedure, so I'm also pasting commands. Sometimes when I paste commands, I get PuTTY Fatal Error: Incoming packet was garbled on decryption. (Disconnected.) It's not a MTU thing. (First of all, I checked all the MTU's looking for any problems) but a better clue is that I can paste the same command over and over and over (obviously the same packet size each time) and it only fails after the Nth repititon. For testing purposes, I ssh into box, and I paste this command: echo hello there buddy, whatcha doing /dev/null Obviously nowhere near the MTU size. I keep pasting it over and over, until connection fails. Count how many times I can successfully paste it before failure. Repeat. My results were: 5, 0, 12, 0, 9, 0. Deterministic inputs, nondeterministic outputs. (Well, probably deterministic, but not determined by the inputs that I'm controlling). I have a workaround. I ssh into some other machine in the network, and then ssh to the machine in question. Infinite success. Paste the above command until my fingers are tired and I'm satisfied that there's no problem. The problem *only* happens when I ssh (or vnc or whatever) directly to the machine from the vpn client. And obviously, it doesn't happen when I ssh to some other machine from the vpn client (and then ssh to the machine in question). The only difference between the LAN traffic which works perfectly, and the VPN traffic that's having a problem, is the fact that the VPN traffic needs to go through a router. It's not the router that's messing up the traffic, or else I would expect to see the same problem on a different machine. It's hard for me to imagine a driver problem that will only affect traffic that requires a router. But maybe. Maybe there's a broadcom driver problem, that doesn't affect LAN traffic but does affect traffic going through a router. Anyway, I'm at a loss for how to debug further. I suppose I could create a dummy network with a really simple router in between, and see if the problem persists, using a different router and no VPN. Also, if I do that, I'll be able to wireshark both sides, to see what happens. For now, on my VPN, I can only wireshark the OI side of the equation; can't wireshark the traffic at my VPN endpoint. I also have one Intel NIC I can stick into one of the machines. ___ OpenIndiana-discuss mailing list OpenIndiana-discuss@openindiana.org http://openindiana.org/mailman/listinfo/openindiana-discuss
Re: [OpenIndiana-discuss] weird packet garbling problem
On 2013-02-02 16:32, Edward Ned Harvey (openindiana) wrote: I am having a really hard time coming up with a plausible explanation for this, other than some kind of kernel bug with openindiana... This may be a (well-known) problem between hardware TCP offload and IPFilter. Basically, the hardware inserts such changes into packets that the filter either drops them or processes and some CRCs become invalid. This happens on various OSes. My memory may be garbled now (maybe this only pertains to NAT, maybe to any firewalling?), but I think Darren Reed on this list might fix my description or add more insight if needed ;) See this thread for example (and links): http://permalink.gmane.org/gmane.comp.security.firewalls.ipfilter/8541 http://comments.gmane.org/gmane.comp.security.firewalls.ipfilter/6026 Basically, the workaround for us was to enable this line in /etc/system: set ip:dohwcksum = 0 to disable hardware offload - so that IPFilter works on original packets, and reboot. And yes, we (and others with the problem) had the bge interfaces which are too smart for our own good. HTH, //Jim I have two systems in the office, Dell PowerEdge SC 1435 (Embedded Broadcom 5721 NIC) and Dell PowerEdge 2950 (Embedded Broadcom 5708 NIC), both running OI 151a5 or newer. Inside the office, everything works fine. But when I go home and VPN into the office, I ssh or vnc to these two boxes, and I get packet garbling and retransmissions and dropped connections, but *only* on these two machines, and *only* from the vpn connection, and *only* for certain specific types of traffic. Here's an example: I'm on an ssh prompt. I can type in commands all day and night, it always works fine when I'm typing. (One character at a time, typing via keyboard, I can hold down a key and completely fill the screen, 4320 keystrokes no problem.) But I'm following a procedure, so I'm also pasting commands. Sometimes when I paste commands, I get PuTTY Fatal Error: Incoming packet was garbled on decryption. (Disconnected.) It's not a MTU thing. (First of all, I checked all the MTU's looking for any problems) but a better clue is that I can paste the same command over and over and over (obviously the same packet size each time) and it only fails after the Nth repititon. For testing purposes, I ssh into box, and I paste this command: echo hello there buddy, whatcha doing /dev/null Obviously nowhere near the MTU size. I keep pasting it over and over, until connection fails. Count how many times I can successfully paste it before failure. Repeat. My results were: 5, 0, 12, 0, 9, 0. Deterministic inputs, nondeterministic outputs. (Well, probably deterministic, but not determined by the inputs that I'm controlling). I have a workaround. I ssh into some other machine in the network, and then ssh to the machine in question. Infinite success. Paste the above command until my fingers are tired and I'm satisfied that there's no problem. The problem *only* happens when I ssh (or vnc or whatever) directly to the machine from the vpn client. And obviously, it doesn't happen when I ssh to some other machine from the vpn client (and then ssh to the machine in question). The only difference between the LAN traffic which works perfectly, and the VPN traffic that's having a problem, is the fact that the VPN traffic needs to go through a router. It's not the router that's messing up the traffic, or else I would expect to see the same problem on a different machine. It's hard for me to imagine a driver problem that will only affect traffic that requires a router. But maybe. Maybe there's a broadcom driver problem, that doesn't affect LAN traffic but does affect traffic going through a router. Anyway, I'm at a loss for how to debug further. I suppose I could create a dummy network with a really simple router in between, and see if the problem persists, using a different router and no VPN. Also, if I do that, I'll be able to wireshark both sides, to see what happens. For now, on my VPN, I can only wireshark the OI side of the equation; can't wireshark the traffic at my VPN endpoint. I also have one Intel NIC I can stick into one of the machines. ___ OpenIndiana-discuss mailing list OpenIndiana-discuss@openindiana.org http://openindiana.org/mailman/listinfo/openindiana-discuss
Re: [OpenIndiana-discuss] weird packet garbling problem
As an alternate thought, what OSes and NICs are running on your router, VPN box (and what sort of VPN is that?), and on those boxes where you don't have the problem? I might guess that if the problem happens with Solaris/OI boxes and does not, for example, happen to Linux and Windows, this might mean that your network gear mangles packets in some way (why not - VPN and NAT and even software VLAN might do strange wonders), and while other OSes might be less picky about packet consistency mismatches, the IP engine in Solaris (or IPFilter) might be more picky and thus fail... Or maybe all of the above and the hardware offload (which of course is not a feature of only bge). From those threads I linked, I incurred that Solaris 10+ should be (have been?) able to detect and disable or collaborate with hardware features, at least on some NICs. It may be that for example e1000g won't show this behavior (being detected by the engine and either degraded to no offload, or worked-around otherwise), and bge's - not so for some reason... Again, here I can only speculate, and there are more knowledgeable experts on the list. Good luck, //Jim Klimov ___ OpenIndiana-discuss mailing list OpenIndiana-discuss@openindiana.org http://openindiana.org/mailman/listinfo/openindiana-discuss
Re: [OpenIndiana-discuss] weird packet garbling problem
Thanks Jim! I've seen similar behavior to what Ed described on a Solaris 10 Sparc box (V445) that is in a remote office. I'll try that setting and see if it resolves my issue. I was VNCing in to an OI box in my office from my laptop via VPN and sshing in to the V445 box to kick off some backup scripts (which take a long time to run, due to the slow link to this office). Oddly enough I never had any issues with the automounter or nfs share I was backing up the V445 to. One issue was with the ssh connection between my OI desktop and the V445 dropping out (note there is very little text output in my backup script) after an hour or two. My other issue was having the VNC drop out between my laptop and desktop. It was setup as a persistent session, so no big deal, just annoying. I think the V445 interfaces are bge and the OI desktop is e1000g. Jake ___ OpenIndiana-discuss mailing list OpenIndiana-discuss@openindiana.org http://openindiana.org/mailman/listinfo/openindiana-discuss
Re: [OpenIndiana-discuss] weird packet garbling problem
On 2013-02-02 18:26, Jake Young wrote: Thanks Jim! I've seen similar behavior to what Ed described on a Solaris 10 Sparc box (V445) that is in a remote office. I think we had something similar too on another setup, but the failure involved larger packets, i.e. in SCP sessions timing out at 192KB or so. Note the multiple of power of two in the problem ;) I recall that the solution had to do with either MTU or the TCP window, something was mismatched with the deployment's provider. I think it was a smaller MTU on an intermediate link, and the overflow errors added up. Maybe the firewall refused fragmented packets or some of the service packets needed to dynamically reduce MTU, also... IIRC, they ultimately forced a smallish MTU on the internet-facing ethernet NIC (further connected to a DSL-Ethernet modem), and this solved the problem for them... Today I'd look at SSH-HPC extensions which may improve buffering and windowing and such for the bulky SSH sessions. Maybe it can help the running job adapt to changing networking conditions. HTH, //Jim I'll try that setting and see if it resolves my issue. I was VNCing in to an OI box in my office from my laptop via VPN and sshing in to the V445 box to kick off some backup scripts (which take a long time to run, due to the slow link to this office). Oddly enough I never had any issues with the automounter or nfs share I was backing up the V445 to. One issue was with the ssh connection between my OI desktop and the V445 dropping out (note there is very little text output in my backup script) after an hour or two. My other issue was having the VNC drop out between my laptop and desktop. It was setup as a persistent session, so no big deal, just annoying. I think the V445 interfaces are bge and the OI desktop is e1000g. Jake ___ OpenIndiana-discuss mailing list OpenIndiana-discuss@openindiana.org http://openindiana.org/mailman/listinfo/openindiana-discuss
Re: [OpenIndiana-discuss] weird packet garbling problem
On 2013-02-02 18:26, Jake Young wrote:
Oddly enough I never had any issues with the automounter or nfs share I was
backing up the V445 to. One issue was with the ssh connection between my
OI desktop and the V445 dropping out (note there is very little text output
in my backup script) after an hour or two. My other issue was having the
Speculating on these points, I'd suggest that:
1) NFS is by default over UDP, which may be more resilient to dropped
packets and adaptation to smaller sizes can be natively bundled.
The higher-layer programs above UDP (i.e. NFS) have to detect and
retry the transmissions, however - unlike TCP which should handle
this sort of problems but may lag until it delivers its payload of
bytes (the sliding window, usually several typical packets in
size).
2) SSH drop-out may be timeout-related... See if your server and/or
client can use (TCP)KeepAlive, or if the script could output more
data to keep the connection active. Timeouts might be related
to the IPFilter (NAT entry age, size of session bucket, etc).
3) Speaking of the latter, we had a problem on our firewall with the
default IPFilter session bucket being very small. I am not sure
if this was solved in later releases, we applied a fix like this
at the time (and it's still running):
[root@newgw /lib/svc/method]# gdiff -bu ipfilter.snv_129-orig ipfilter
--- ipfilter.snv_129-orig 2009-11-27 01:07:18.0 +0300
+++ ipfilter2010-06-29 14:07:36.034883267 +0400
@@ -153,7 +153,12 @@
create_services_rules || exit $SMF_EXIT_ERR_CONFIG
[ ! -f ${IPFILCONF} -a ! -f ${IPNATCONF} ] exit 0
- ipf -E
+
+ ### Enforce and display state-table sizing
+ ### Jim Klimov, 2009-2010
+ipf -D -T
fr_statemax=72901,fr_statesize=104147,fr_statemax,fr_statesize -E -T
fr_statemax,fr_statesize
+ # ipf -E
+
load_ippool || exit $SMF_EXIT_ERR_CONFIG
load_ipf || exit $SMF_EXIT_ERR_CONFIG
load_ipnat || exit $SMF_EXIT_ERR_CONFIG
In fact, in OI 151a7 I see that the values are set to 5, so
it seems, while on older Sol10u8 and SXCE it is around 4000.
Our values were from trial-and-error somewhat; and I think there
was some math to them as well (google or ask Darren) ;)
HTH,
//Jim
___
OpenIndiana-discuss mailing list
OpenIndiana-discuss@openindiana.org
http://openindiana.org/mailman/listinfo/openindiana-discuss
Re: [OpenIndiana-discuss] new SXCE distribution now available
Hello! OpenSXCE repo seems to have wrong address (or at least it is not in sync with pkgutil's expectations): eg. andrejj@opensxce:~# pkgutil -i SUNWwget = Fetching new catalog and descriptions ( http://svr4.opensxce.org/sparc/5.11) if available ... --2013-02-02 19:35:11-- http://svr4.opensxce.org/sparc/5.11/catalog Resolving svr4.opensxce.org (svr4.opensxce.org)... failed: node name or service name not known. wget: unable to resolve host address `svr4.opensxce.org' Fetching of catalog failed. I can not find any workaround to get it (pkgutil withOpenSXCE repo.) working. After changing pkgutil.conf I'm able to get files from CSW repo. Best Regards Andrej On Fri, Feb 1, 2013 at 10:27 PM, Al Hopper a...@logical-approach.com wrote: Done! The md5sum is 330a82654405c77c8cea903ed18117f2 And yes - it's logical dash approach dot com (sorry about that) On Fri, Feb 1, 2013 at 3:17 PM, Jan Owoc jso...@gmail.com wrote: Hi Al, On Thu, Jan 31, 2013 at 12:29 PM, Al Hopper a...@logical-approach.com wrote: Martin Bochnig has developed a new Solaris distribution called SXCE. It's available at http://www.opensxce.org My involvement in this project is simply to provide a distribution mechanism for Martins work. So, all the credit for this work belongs to Martin and all the complaints related to the quick and dirty opensxce.org website should be sent to me at al at logical dot approach dot com. I think this was mentioned in another thread, but could you post the md5sums (and/or another checksum) on the site? With such a large download, many people may wish to verify it. Cheers, Jan P.S. Your e-mail is ... at logical *dash* approach, right? I got a failure otherwise. -- Al Hopper ___ OpenIndiana-discuss mailing list OpenIndiana-discuss@openindiana.org http://openindiana.org/mailman/listinfo/openindiana-discuss ___ OpenIndiana-discuss mailing list OpenIndiana-discuss@openindiana.org http://openindiana.org/mailman/listinfo/openindiana-discuss
Re: [OpenIndiana-discuss] weird packet garbling problem
On Sat, 2 Feb 2013, Jim Klimov wrote: On 2013-02-02 18:26, Jake Young wrote: Oddly enough I never had any issues with the automounter or nfs share I was backing up the V445 to. One issue was with the ssh connection between my OI desktop and the V445 dropping out (note there is very little text output in my backup script) after an hour or two. My other issue was having the Speculating on these points, I'd suggest that: 1) NFS is by default over UDP, which may be more resilient to dropped packets and adaptation to smaller sizes can be natively bundled. From mount_nfs manual page: By default, the transport protocol that the NFS mount uses is the first available RDMA transport supported both by the client and the server. If no RDMA transport is found, then it attempts to use a TCP transport or, failing that, a UDP transport, as ordered in the /etc/netconfig file. If it does not find a connection oriented transport, it uses the first available connectionless transport. So Solaris NFS mounts use TCP by default. Bob -- Bob Friesenhahn bfrie...@simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/ GraphicsMagick Maintainer,http://www.GraphicsMagick.org/ ___ OpenIndiana-discuss mailing list OpenIndiana-discuss@openindiana.org http://openindiana.org/mailman/listinfo/openindiana-discuss
Re: [OpenIndiana-discuss] weird packet garbling problem
From: Jim Klimov [mailto:jimkli...@cos.ru] Basically, the workaround for us was to enable this line in /etc/system: set ip:dohwcksum = 0 Oh well, thanks for the suggestion... Unfortunately, didn't make any difference... ___ OpenIndiana-discuss mailing list OpenIndiana-discuss@openindiana.org http://openindiana.org/mailman/listinfo/openindiana-discuss
Re: [OpenIndiana-discuss] new SXCE distribution now available
Use the repo link as posted on the opensxce website for now. -- On Sat, Feb 2, 2013 1:39 PM EST Andrej Javoršek wrote: Hello! OpenSXCE repo seems to have wrong address (or at least it is not in sync with pkgutil's expectations): eg. andrejj@opensxce:~# pkgutil -i SUNWwget = Fetching new catalog and descriptions ( http://svr4.opensxce.org/sparc/5.11) if available ... --2013-02-02 19:35:11-- http://svr4.opensxce.org/sparc/5.11/catalog Resolving svr4.opensxce.org (svr4.opensxce.org)... failed: node name or service name not known. wget: unable to resolve host address `svr4.opensxce.org' Fetching of catalog failed. I can not find any workaround to get it (pkgutil withOpenSXCE repo.) working. After changing pkgutil.conf I'm able to get files from CSW repo. Best Regards Andrej On Fri, Feb 1, 2013 at 10:27 PM, Al Hopper a...@logical-approach.com wrote: Done! The md5sum is 330a82654405c77c8cea903ed18117f2 And yes - it's logical dash approach dot com (sorry about that) On Fri, Feb 1, 2013 at 3:17 PM, Jan Owoc jso...@gmail.com wrote: Hi Al, On Thu, Jan 31, 2013 at 12:29 PM, Al Hopper a...@logical-approach.com wrote: Martin Bochnig has developed a new Solaris distribution called SXCE. It's available at http://www.opensxce.org My involvement in this project is simply to provide a distribution mechanism for Martins work. So, all the credit for this work belongs to Martin and all the complaints related to the quick and dirty opensxce.org website should be sent to me at al at logical dot approach dot com. I think this was mentioned in another thread, but could you post the md5sums (and/or another checksum) on the site? With such a large download, many people may wish to verify it. Cheers, Jan P.S. Your e-mail is ... at logical *dash* approach, right? I got a failure otherwise. -- Al Hopper ___ OpenIndiana-discuss mailing list OpenIndiana-discuss@openindiana.org http://openindiana.org/mailman/listinfo/openindiana-discuss ___ OpenIndiana-discuss mailing list OpenIndiana-discuss@openindiana.org http://openindiana.org/mailman/listinfo/openindiana-discuss ___ OpenIndiana-discuss mailing list OpenIndiana-discuss@openindiana.org http://openindiana.org/mailman/listinfo/openindiana-discuss
Re: [OpenIndiana-discuss] weird packet garbling problem
On Sat, 2 Feb 2013, Edward Ned Harvey (openindiana) wrote: From: Jim Klimov [mailto:jimkli...@cos.ru] Basically, the workaround for us was to enable this line in /etc/system: set ip:dohwcksum = 0 Oh well, thanks for the suggestion... Unfortunately, didn't make any difference... Unless TCP is offloaded from the kernel (so that checksums are in an adaptor card), it is exceedingly difficult for wrong data to pass TCP's checksumming and get passed up to the socket that SSH uses. However the other end, or an intermediary (e.g. router), can send certain TCP packets (and/or ICMP packets) which cause the connection to be aborted. The using software may not be properly prepared to deal with TCP connections going away at some random time and may mis-diagnose the problem. This is particularly an issue with software using the poll() system call, from which state changes need to be evaluated in a particular order or else the wrong diagnosis will be made. Regardless, PUtty is Windows sofware so it is subject to Windows TCP/IP stack behavior. Bob -- Bob Friesenhahn bfrie...@simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/ GraphicsMagick Maintainer,http://www.GraphicsMagick.org/ ___ OpenIndiana-discuss mailing list OpenIndiana-discuss@openindiana.org http://openindiana.org/mailman/listinfo/openindiana-discuss
[OpenIndiana-discuss] Success at last!
I got the N40L built w/ OI_151a7 using the LiveCD. Jim's suggestion of a small MBR partition was the key. It's a messy process though. I've got a page on the wiki under storage that sort of describes the process. I'll fill in more detail later. I'm a bit nervous that I've missed a detail. I got beat up pretty badly by issues introduced by the 4k sectors and various rabbit holes making all the number match. The cylinders on the ST2000DM001 are not multiples of 4k. That doesn't seem to matter, but it wasted a lot of time. There's a real need for something simpler for installing a NAS w/ a regular GUI console. I like my text windows. I created a 3x30 GB mirrored rpool and a 3 disk RAIDZ dpool. I've got 3.5 TB available in the RAIDZ pool and a 64 GB write of /dev/zero reported 199 MB/s. It even boots if I remove a disk w/o having to hit F10, so the N40L BIOS is not completely hopeless. Thanks a lot for all the help and guidance. Now to get my head around writing bug reports on format(1m) and fmthard(1m) and possibly some other things. Have Fun! Reg ___ OpenIndiana-discuss mailing list OpenIndiana-discuss@openindiana.org http://openindiana.org/mailman/listinfo/openindiana-discuss
Re: [OpenIndiana-discuss] weird packet garbling problem
From: Bob Friesenhahn [mailto:bfrie...@simple.dallas.tx.us] Unless TCP is offloaded from the kernel (so that checksums are in an adaptor card), it is exceedingly difficult for wrong data to pass TCP's checksumming and get passed up to the socket that SSH uses. In the one packet capture that I was able to do so far, running wireshark on the OI side of the connection, I saw all the checksums were 0's and triggering the bad checksum flag in wireshark. When I googled around, some wireshark FAQ said if all your bad checksums are 0's and only on sent packets (not received packets) then it means the checksumming is happening at a layer lower than wireshark, and you can ignore the errors, by toggling a checkbox. This fit the description, so I did it. A lower layer might be either kernel or hardware; I don't know. The second thing I saw was ... For every time I sent/received a single character (typing on my keyboard) the OI system received an ssh packet, sent an ssh packet (terminal echo), and sent an ssh ACK for the first packet. But then when I pasted some command that caused the failure ... the OI machine saw the packet come in, and get repeated like 100 times all within 1ms of each other. Then it spewed out like 100 responses, all with about 1ms, and wireshark flagged as error, like 100 duplicate ACKs, that were again, all within like 1ms. And the TCP FIN. ... I know my laptop didn't send like 100 times. (First of all, it happened too quickly for that to be possible, second, it only happens when connected to an OI server, third, it happens for both ssh and vnc traffic.) It's the sort of thing that makes me suspect some sort of faulty interrupt or interrupt handler. The more I think about it, the more I am suspicious of the broadcom NIC driver. ___ OpenIndiana-discuss mailing list OpenIndiana-discuss@openindiana.org http://openindiana.org/mailman/listinfo/openindiana-discuss
Re: [OpenIndiana-discuss] new SXCE distribution now available
That issue has been resolved. Please contact me directly if you encounter any other issues with opensxce.org Thanks, Al Hopper On Sat, Feb 2, 2013 at 12:39 PM, Andrej Javoršek dr...@ntf.uni-lj.siwrote: Hello! OpenSXCE repo seems to have wrong address (or at least it is not in sync with pkgutil's expectations): eg. andrejj@opensxce:~# pkgutil -i SUNWwget = Fetching new catalog and descriptions ( http://svr4.opensxce.org/sparc/5.11) if available ... --2013-02-02 19:35:11-- http://svr4.opensxce.org/sparc/5.11/catalog Resolving svr4.opensxce.org (svr4.opensxce.org)... failed: node name or service name not known. wget: unable to resolve host address `svr4.opensxce.org' Fetching of catalog failed. I can not find any workaround to get it (pkgutil withOpenSXCE repo.) working. After changing pkgutil.conf I'm able to get files from CSW repo. Best Regards Andrej On Fri, Feb 1, 2013 at 10:27 PM, Al Hopper a...@logical-approach.com wrote: Done! The md5sum is 330a82654405c77c8cea903ed18117f2 And yes - it's logical dash approach dot com (sorry about that) On Fri, Feb 1, 2013 at 3:17 PM, Jan Owoc jso...@gmail.com wrote: Hi Al, On Thu, Jan 31, 2013 at 12:29 PM, Al Hopper a...@logical-approach.com wrote: Martin Bochnig has developed a new Solaris distribution called SXCE. It's available at http://www.opensxce.org My involvement in this project is simply to provide a distribution mechanism for Martins work. So, all the credit for this work belongs to Martin and all the complaints related to the quick and dirty opensxce.org website should be sent to me at al at logical dot approach dot com. I think this was mentioned in another thread, but could you post the md5sums (and/or another checksum) on the site? With such a large download, many people may wish to verify it. Cheers, Jan P.S. Your e-mail is ... at logical *dash* approach, right? I got a failure otherwise. -- Al Hopper ___ OpenIndiana-discuss mailing list OpenIndiana-discuss@openindiana.org http://openindiana.org/mailman/listinfo/openindiana-discuss ___ OpenIndiana-discuss mailing list OpenIndiana-discuss@openindiana.org http://openindiana.org/mailman/listinfo/openindiana-discuss -- Al Hopper ___ OpenIndiana-discuss mailing list OpenIndiana-discuss@openindiana.org http://openindiana.org/mailman/listinfo/openindiana-discuss
