This may be totally offbase - but is it possible that it's just an ethernet
device port negotiation issue (one port in full-duplex mode connecting to a
port in half-duplex)?
Regards,
Al Hopper
On Wed, Feb 6, 2013 at 6:22 AM, Edward Ned Harvey (openindiana) <
openindi...@nedharvey.com> wrote:
>
> From: Roel_D [mailto:openindi...@out-side.nl]
>
> I use ASA5505's always. I never had this problem with solaris 10&11, but
> those run on sun hardware.
> I also have solaris 10 on an old HP DL340 with bge's also without problem.
> And OI 1.57 on VMware also without the problems you describe.
> I
I use ASA5505's always. I never had this problem with solaris 10&11, but those
run on sun hardware.
I also have solaris 10 on an old HP DL340 with bge's also without problem.
And OI 1.57 on VMware also without the problems you describe.
I use the cisco VPN windows client.
Is your cisco the def
> From: Edward Ned Harvey (openindiana)
> [mailto:openindi...@nedharvey.com]
>
> I am having a really hard time coming up with a plausible explanation for
> this,
> other than some kind of kernel bug with openindiana...
Found a new clue, which is totally unbelievable, yet totally enlightening.
On 02/04/13 10:01, Edward Ned Harvey (openindiana) wrote:
>> From: James Carlson [mailto:carls...@workingcode.com]
>>
>> Which of the many Broadcom drivers is this? If it's bnx, try editing
>> /kernel/drv/bnx.conf, and uncommenting and changing the "checksum="
>> line
>> to set it to all zeros.
>
> From: James Carlson [mailto:carls...@workingcode.com]
>
> Which of the many Broadcom drivers is this? If it's bnx, try editing
> /kernel/drv/bnx.conf, and uncommenting and changing the "checksum="
> line
> to set it to all zeros.
One of the systems is using bge, and the other is using bnx.
I
You said: "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"
So OI first received 100 messages, although unkn
On 2/2/2013 11:36 PM, Edward Ned Harvey (openindiana) wrote:
> The more I think about it, the more I am suspicious of the broadcom NIC
> driver.
Which of the many Broadcom drivers is this? If it's bnx, try editing
/kernel/drv/bnx.conf, and uncommenting and changing the "checksum=" line
to set it
> 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
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 TC
> 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-di
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
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 ho
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 192
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 s
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
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 hardwa
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
151a
18 matches
Mail list logo
