Linux - NetworkingThis forum is for any issue related to networks or networking.
Routing, network cards, OSI, etc. Anything is fair game.
Notices
Welcome to LinuxQuestions.org, a friendly and active Linux Community.
You are currently viewing LQ as a guest. By joining our community you will have the ability to post topics, receive our newsletter, use the advanced search, subscribe to threads and access many other special features. Registration is quick, simple and absolutely free. Join our community today!
Note that registered members see fewer ads, and ContentLink is completely disabled once you log in.
If you have any problems with the registration process or your account login, please contact us. If you need to reset your password, click here.
Having a problem logging in? Please visit this page to clear all LQ-related cookies.
Get a virtual cloud desktop with the Linux distro that you want in less than five minutes with Shells! With over 10 pre-installed distros to choose from, the worry-free installation life is here! Whether you are a digital nomad or just looking for flexibility, Shells can put your Linux machine on the device that you want to use.
Exclusive for LQ members, get up to 45% off per month. Click here for more info.
But doesnt the SRC=172.xx.xx.xx DST=216.xxx.xxx.xxx line mean that the src of the ssh connection is the server thats locking up (172.ip) and that its trying to reach the destination IP 216.?
No. Read Chort's first response. This packet is outbound, but, looking at the accompanying data, you can see that ACK is on for this packet. That is, this is the ACK packet out of a SYN/ACK handshake sequence. In other words, this is an outbound packet in an incoming connection initiated from the other end.
It is not clear why you will not look up the owner of the 216.xxx.xxx.xxx IP address. If you are having some miscreant trying to login via ssh, that is your culprit.
But they at least used randomization. Every production version of Linux that I've taken a tcpdump from hasn't used any IP Id randomization at all, they all increment by 2.
Edit: This was fixed less than two weeks later. The OpenBSD team based their fix off the one for DragonflyBSD, but did a lot of additional testing rather than rush to get a band-aid in place. There are a lot of other commits over the next few months that further strengthened the randomization in various networking components (read the CVS commit message e-mail archive).
Log message:
replacement algorithm. initialize a 64K-short buffer using Durstenfeld
shuffle. Upon allocation, swap-permute the new value to a random slot in
the 0..32K-1 th entry of the buffer as we move forward, ensuring randomness
but also satisfying the non-repeating property we need. Also avoid the value
of 0, since IP ID's of 0 are special. Inspired by Dillon's implementation.
We believe this is easier to read though, initializes with less bias, handles
the ID of 0 properly, and wins speed tests.
Thanks a lot to mcbride and djm for doing a bunch of statistical and speed
analysis, and comments from nordin
ok mcbride djm
Last edited by chort; 07-25-2008 at 03:21 AM.
Reason: more info
LinuxQuestions.org is looking for people interested in writing
Editorials, Articles, Reviews, and more. If you'd like to contribute
content, let us know.
