similar to: Not Responding To TCP Connections

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi folks. Please, someone confirm if i'm right. if i'm wrong, please forgive-me. - -------------------------------------------------------------------------------------------------------------- I've developed a little tool to stress test tcp connections.( Sending syn and answer ack-syn ). that simuates a real tcp connection. (

Last week, I started seeing very strange behavior in one of the networks that I manage. The office LAN uses a Linux firewall which masquerades their workstations over their DSL connection. There are probably ~75 workstations in the office LAN. Their mail server is in a collocated facility nearby. That server has an RFC1918 address; its router does SNAT to forward packets to the system. Both

Hello, My first post on Xen-Users, so .. i''ve discovered a strange problem. Setup: -A Windows server 2003R2 (x86) with GPL PV driver 0.9.9 ipferf 1.7.0 (from 2003) -dom0 a opensuse 11.0 xen: # rpm -q -a |grep -i xen kqemu-kmp-xen-1.3.0pre11_2.6.25.5_1.1-7.1 kiwi-desc-xenboot-2.38-67.1 xen-3.2.1_16881_04-4.2 xen-tools-3.2.1_16881_04-4.2 xen-libs-3.2.1_16881_04-4.2

Hello, I current have a FreeBSD 4.8 bridge firewall that sits between 7 servers and the internet. The servers are being attacked with syn floods and go down multiple times a day. The 7 servers belong to a client, who runs redhat. I am trying to find a way to do some kind of syn flood protection inside the firewall. Any suggestions would be greatly appreciated. -- Ryan James ryan@mac2.net

Hi Guys, My Debian box has been hacked a few days ago using an OpenSSH vulnerability. Subsequently my box was used for sending spam and as a hacking platform (according to my ISP). I was running a fairly recent version of OpenSSH (3.9p1). I reinstalled my box (now with 3.8p1 as supplied by Debian Stable), and started tcpdump to see if I would get lucky. I DID! The aut.log file shows the

Tom wrote : >My advice to you is still the same -- you are going to have to use tcpdump >or ethereal to see what is happening. You have the computer there in front >of you >-- we don''t. So only you are going to be able to solve this. We are not. >From the dump you sent, it looks like many SYN packets are being sent on >ppp0 >and never replied to. So you need to

Hi, I have shorewall version 1.4.10g on Redhat 9 Local clients are on eth1 in subnet 192.168.3.0/24. eth0 is for the outside (over xdsl with includes a ppp0 interface). Nessus (nessusd) is installed *on the firewall* and managed trough nessus (the client or frontend) running on one of the internal machines. When I was running a scan against 194.152.181.36 I observed several entries like

Hi, On Mon, Feb 26, 2018 at 11:32:26AM +0000, Kim Minh Kaplan wrote: > TL;DR: please try the patch out and report if it causes "Did not receive > identification string" log messages. I believe it does not. It depends on absolute RTT to the target. If you stay local ("< 50ms"), the 250ms offset should reliably avoid DNIS logs. If you happen to connect to Australia

I have found a very strange problem. We found that the time of establishing the websocket connection between mobile phone and server was too long. Then I use tcpdump to capture the data and found that the problem maybe has something to do with window scale option in SYN packet. Here is the SYN packet for websocket connection: 55488 ? 443 [SYN] Seq=0 Win=65535 Len=0 MSS=1460 WS=64

Hi. I don''t know if this one is known, but I can''t recall seeing anything about it. If it is old news I apologize. I discovered a bug in the inetd that comes with NetKit-B-0-08 and older. If a single SYN is sent to port 13 of the server, inetd will die of Broken Pipe: write(3, "Sun Jan 12 21:50:35 1997\r\n", 26) = -1 EPIPE (Broken pipe) --- SIGPIPE (Broken pipe) ---

Commits: fd2a0437dc33 virtio_net: introduce virtio_net_hdr_{from,to}_skb e858fae2b0b8 virtio_net: use common code for virtio_net_hdr and skb GSO conversion introduced a subtle (but unexplained) difference in how virtio_net flags are derived from skb->ip_summed fields on transmit from the guest to the host/backend. Prior to the patches the flags would be set to VIRTIO_NET_HDR_F_NEEDS_CSUM if

Commits: fd2a0437dc33 virtio_net: introduce virtio_net_hdr_{from,to}_skb e858fae2b0b8 virtio_net: use common code for virtio_net_hdr and skb GSO conversion introduced a subtle (but unexplained) difference in how virtio_net flags are derived from skb->ip_summed fields on transmit from the guest to the host/backend. Prior to the patches the flags would be set to VIRTIO_NET_HDR_F_NEEDS_CSUM if

Enjoy.... ugh. Dan ____________________________________________________________________________ Dan Yocum | Phone: (630) 840-8525 Computing Division OSS/FSS | Fax: (630) 840-6345 .~. L Fermi National Accelerator Lab | email: yocum@fnal.gov /V\ I P.O. Box 500 | WWW: www-oss.fnal.gov/~yocum/ // \\ N Batavia, IL

Hello all, I've got an issue I'm almost positive is not related to Dovecot, but was wondering whether anyone else has had similar problems or could duplicate my results. Please accept my apologies if this is considered off-topic or this issue is actually just a symptom of my own ignorance. Also, sorry for how long this email got, I knew I wouldn't be able to explain my issue in

Hello All, We have a Linux cluster application that uses openssh as its inter-node communication mechanism and we've recently run into a problem that points to a potential scalability issue in openssh code. Our client nodes systematically open ssh connections to the server node to execute an administrative command. When establishing socket connections, the server side sometimes fails to

Maybe this is the right place to ask? Thanks again, Daniel Begin forwarded message: > From: Daniel Schaffrath <daniel.schaffrath@mac.com> > Date: 21 July 2007 11:01:01 GMT+02:00 > To: linux-net@vger.kernel.org > Subject: PFIFO to contain more pkts than allowed by TCP peer? > > Hello everybody, > > when the one and only connection originating my box is a TCP stream

Hi, First of all, I know that not dropping SYN/FIN isn't really a big deal, it just makes no sense. But since it doesn't make any sense, I don't see the reason why not to discard them. I'm running pf on FreeBSD 5.4-RELEASE-p3 and I scrub any traffic. I've read some other posts on google and as far as I can tell, clearly invalid packets (like packets with SYN/RST set) is

A bit off topic, but I keep looking for an answer to this question and coming up with nothing... so I thought I would go to the gurus. :-) Can anyone recommend a good package for pinging other devices and sending an email/alert when they go down? I'm aware of all kinds of more complex things with GUIs and a zillion other bells and whistles we aren't looking for, but we just want a simple

So after several days of more troubleshooting, I have some things to report to the list. First and foremost, I have discovered that the issue has nothing to do with SSL/TLS, which was my earlier suspicion because after doing some PCAPs I discovered that the transactions were negotiating TLS 1.2 on the new server, as opposed to 1.0 on the old. Also thank you for the rawlog suggestion: that

Those speed tests are best case scenario - one big old file where the only overhead would be tcp syn/acks. 5000 x syn/acks and handshakes everytime a client connects would quite a lot of overhead I imagine. Note that this is an educated guess - I don't run /anything/ on the scale of 5000 users lol ---- Jordan Erickson wrote ---- >Hi Frederick, > >Wouldn't overhead (at least