Re: ssh & select() problem on 5.3
From: Alin-Adrian Anton (aanton_at_spintech.ro)
Date: 11/28/04
- Previous message: Barney Wolff: "Re: ssh & select() problem on 5.3"
- In reply to: Barney Wolff: "Re: ssh & select() problem on 5.3"
- Next in thread: David Malone: "Re: ssh & select() problem on 5.3"
- Reply: David Malone: "Re: ssh & select() problem on 5.3"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Date: Sun, 28 Nov 2004 20:30:03 +0200 To: Barney Wolff <barney@databus.com>, freebsd-current@freebsd.org, freebsd-hackers@freebsd.org
Hi,
Barney Wolff wrote:
>
> Perhaps an MTU problem, with the ICMP "fragmentation needed but DF set"
> being blocked by the firewall? It would only show up when the server
> has enough to send to fill a packet.
>
I'm the friend he was talking about.
The very same thing happens when the firewall is disabled.
I tried from 5.2.1 console and same thing happens. However, we were
unable to reproduce the problem on any other servers. It only happens there.
No, it's not an ssh bug. I wrote a connect-back snippet and the same
thing happens when running commands with relatively big output (like dmesg).
I tried logging from 5.2.1 and 5.3 to different servers behind his
firewall, running also 5.3 and 5.2.1. The results are similar for all
the possible combinations.
A tcpdump shows that what actually happens is that packets won't reach
me in spite of the fact that his firewall(router)'s tcpdump shows that
he keeps sending them to me. Packets never reach me, but I am still able
to send them, by pressing ENTER on the ssh console.
Interesting fact is that I also get ACK packets for each of the packet I
send by pressing ENTER. However this is useless, as the connection is
already desynced and I receive no output. The connection times out in 5
minutes.
I hope I didn't use a way too obfuscated English.
PS: I personally suspect a hardware failure, probably an ethernet card,
and he is going to check this out tomorrow.
Regards,
-- Alin-Adrian Anton Spintech Systems GPG keyID 0x1E2FFF2E (2963 0C11 1AF1 96F6 0030 6EE9 D323 639D 1E2F FF2E) gpg --keyserver pgp.mit.edu --recv-keys 1E2FFF2E _______________________________________________ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org"
- Previous message: Barney Wolff: "Re: ssh & select() problem on 5.3"
- In reply to: Barney Wolff: "Re: ssh & select() problem on 5.3"
- Next in thread: David Malone: "Re: ssh & select() problem on 5.3"
- Reply: David Malone: "Re: ssh & select() problem on 5.3"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Relevant Pages
- Re: port 80 is open
... you said above would be true if a software firewall is used since that is ...
the PC so the ISP's router would see the hardware firewall but not the PC ... ISP would
know that I am active since it would see packets coming from me ... If you have a connection
to your ISP at all (you have a piece ... (comp.security.firewalls) - Re: Freeswan IPsec routing problem... ;^(
... > I forgot to mention that my ADSL connection is based on Dinamyc IPs, ...
the default gateway is the place that a machine directs all packets it doesn't ... an address
*behind* the other firewall. ... the tunnel leave via ipsec0 and will not be NAT'd
then. ... (comp.os.linux.security) - Re: strange network traffic
... On the not having a firewall issue, there is an alternative solution: ... A
rude alternative is to sent RST and just drop the connection. ... Now, the parallel firewall
wil sniff all packets on the segment, and ... leave the network. ... (Security-Basics) - Re: iptables and dhcp
... > the same physical network segment as the firewall and the remote DHCP ...
You used INPUT and not FORWARD chain ... # This target allows packets to be marked
in the mangle table ... (comp.os.linux.networking) - Re: Trouble accessing Outlook Web Access from behind firewall
... When starting the firewall I also set ... > rejected and dropped packets
are logged, however I see nothing in my log ... > # Higher ports needed to accept incoming/outgoing
calls ... (comp.security.firewalls)