> Huh? Do you mean a PIX blade in a Cisco switch-router chassis? It
> would be very useful if you could be less vague about the
> equipment in use.
Right it's a PIX blade in Cisco chassis. The PIX is running ASA version 7.0(6)
> That depends more on your customers' networking attributes
> the
> But I'd be very surprised if the router is acting as anything more
> that a network-layer device. It might perhaps have some soft connection
> state being used for generating accounting records. Being Cisco
> it's probably a switch-router, so it might carry some per-port hard
> state for validat
> I still dont understand.
>
> "tcpdump -p -n -s 1600 -c 1" doesnt reveal User data at all.
>
> Without any exact data from you, I am afraid nobody can help.
Oh, I didn't see that you specified specific options. I'll still have
to anonymize 2000+ IP addresses, but I think there is an open sou
> The router could be sooo crappy that it drops all packets from
> TCP streams that have SACK enabled and the client has opened
> 200+ SACK connections previously... something like that?
I don't know, maybe. My router is a fairly new model Cisco and is
pretty major (i.e. pretty expensive), so it'
On 12/19/07, Eric Dumazet <[EMAIL PROTECTED]> wrote:
> James Nichols a écrit :
> >> So you see outgoing SYN packets, but no SYN replies coming from the remote
> >> peer ? (you mention ACKS, but the first packet received from the remote
> >> peer should be a
> So you see outgoing SYN packets, but no SYN replies coming from the remote
> peer ? (you mention ACKS, but the first packet received from the remote
> peer should be a SYN+ACK),
Right, I meant to say SYN+ACK. I don't see them coming back.
> When the problem comes, instead of restarting the
> Well... please dont start a flame war :(
>
> Back to your SYN_SENT problem, I suppose the remote IP is known, so you
> probably could post here the result of a tcdpump ?
>
> tcpdump -p -n -s 1600 host IP_of_problematic_peer -c 500
>
> Most probably remote peer received too many attempts from you,
> Well... please dont start a flame war :(
>
> Back to your SYN_SENT problem, I suppose the remote IP is known, so you
> probably could post here the result of a tcdpump ?
>
> tcpdump -p -n -s 1600 host IP_of_problematic_peer -c 500
>
> Most probably remote peer received too many attempts from you,
> Here is a purely hypothethical (and in practice unlikely) idea:
> Java opens up too many sockets (more than you really request) and the
> kernel, for whatever reason, does not deliver packets to programs
> which have maxed out their fds. Well it would already help if the
> java blob was split int
> >> Well you could still blame Java. I am sure that if you program was C,
> >> the problem could be narrowed down much easier.
> >
> >That may very well be true, but I can't rewrite the whole 500K line
> >application in C at this point. Plus, it's a web app which would be
> >"fun" to implement in
> Well you could still blame Java. I am sure that if you program was C,
> the problem could be narrowed down much easier.
That may very well be true, but I can't rewrite the whole 500K line
application in C at this point. Plus, it's a web app which would be
"fun" to implement in C.
--
To unsubscr
> Try uploading something through rsync+ssh, or scp+ssh. If it aborts
> or hangs after a while, that may be an strong indication of a crappy
> router. Also, I'd advise to upgrade to something newer like >=
> 2.6.22. There was one of those SACK-broken routers around here too,
> but it seemed to have
ebug this problem in the kernel to find out what the root cause is?
I've temporarily signed up on this list, but may opt-out if I can't
handle the traffic, so please CC me directly on any replies.
Thanks,
James Nichols
--
To unsubscribe from this list: send the line "unsubscribe linux-
13 matches
Mail list logo
