"WiFi X" - Page 1
Forum section: electronics / general

author: steve30
author_rank: Frequent Contributor
timestamp: May 23, 2020, 08:50:10 am
content: I just got this 5 minute long advert on Youtube prior to watching an EEVBlog video, so I thought it was worth posting here.It claims that ISPs have a 'dirty secret'; basically traffic shaping, and slow people down in the evenings. Well, traffic shaping in ISPs isn't really a secret. The video shows what appears to be a 'WiFi Repeater' which will improve the range (fair enough), but also claims to bypass this ISP traffic shaping.Here's the website:https://get-wifi-x.com/

author: AVGresponding
author_rank: Super Contributor
timestamp: May 23, 2020, 10:34:41 am
content: Probably just a repeater, which will give a speed boost in poor signal areas of your house I suppose.I don't see how it's possible to bypass ISP speed controls when it's clearly routing through the existing hub anyway

author: Raj
author_rank: Frequent Contributor
timestamp: May 23, 2020, 11:16:46 am
content: Quote from: AVGresponding on May 23, 2020, 10:34:41 amunless the ISP is slowing specific sites and these hubs are making other's hub become their vpn exit nodes(just kidding)a local cache server would definitely speed up frequently visited pages btw.

author: madires
author_rank: Super Contributor
timestamp: May 23, 2020, 11:49:57 am
content: Slow internet access in the evening is mostly caused by lots of users enjoying internet content at the same time and overbooking by the ISP. No need for the ISP to spend much effort in managing complex traffic shaping rules across the network.Circumventing traffic shaping is possible when the ISP did a bad job in configuring QoS for VoIP or other services, i.e. if they only check the DiffServ bits in the IP packet to move a packet to the fast track queue. If they also check for ports and/or IP addresses then it won't work. My guess is that WiFi X simply overwrites the DiffServ bits, something a SOHO router (OpenWRT is great for that) can do also.BTW, it's feasible to offer internet access with user driven QoS and corresponding billing.

author: Jeroen3
author_rank: Super Contributor
timestamp: May 23, 2020, 12:23:42 pm
content: I'm not capable to create more than one pppoe with my ISP. It's point-to-point and the remote router doesn't accept more than 2 (one for ipv4 and one for ipv6).Well, you can bypass traffic shaping by masking the packet signature, but you have to unmask it somewhere. This is what they all a VPN.

author: madires
author_rank: Super Contributor
timestamp: May 23, 2020, 12:24:15 pm
content: Quote from: blueskull on May 23, 2020, 11:41:22 amUsually ISPs/telcos limit throughput at the data link layer because it's the most simple and effective way. At the network layer (IP in this case) it's harder since it will increase the router load. And RADIUS takes care about users trying to establish multiple PPPoE links.

author: madires
author_rank: Super Contributor
timestamp: May 23, 2020, 02:14:39 pm
content: Quote from: Jeroen3 on May 23, 2020, 12:23:42 pmThat setup is a bit strange, since PPP is designed to support multiple protocols in one session. So running IPv4 and IPv6 in one PPPoE link is fully supported. Of course, you can run a PPPoE link for each protocol, but it's uncommon and needs to be supported by the ISP.Side note: An initial intention of PPPoE was that each PC in a LAN could have its own internet access via a shared DSL modem.Quote from: Jeroen3 on May 23, 2020, 12:23:42 pm... and the VPN traffic ends up in the same "best effort" queue as any other traffic.

author: Jeroen3
author_rank: Super Contributor
timestamp: May 23, 2020, 02:42:10 pm
content: The strange pppoe setup is probably because it is the only provider that supports ipv6 in the netherlands.In what traffic shaping group you end up with the vpn depends on how you mask the traffic.

author: madires
author_rank: Super Contributor
timestamp: May 23, 2020, 03:17:01 pm
content: Quote from: Jeroen3 on May 23, 2020, 02:42:10 pmJust one?Because of the lack of IPv4 addresses we already have IPv6-only servers/services.Quote from: Jeroen3 on May 23, 2020, 02:42:10 pm... depends on what your ISP does or supports. They can overwrite any of your DiffServ settings if they like to.

author: NiHaoMike
author_rank: Super Contributor
timestamp: May 24, 2020, 08:53:46 pm
content: In some cases, you actually could get greater bandwidth by running many streams in parallel, usually when the limit is something other than the line to your house. (If you're getting close to the advertised bandwidth, such a device is unlikely to increase it.) Then there's blocking ads so they don't waste bandwidth...

author: TomS_
author_rank: Frequent Contributor
timestamp: June 12, 2020, 07:52:02 pm
content: Quote from: Jeroen3 on May 23, 2020, 02:42:10 pmEh? The ISP shouldn't care what VPN you use, or if you're even using a VPN at all. To them, it's all IP traffic, and they will shape (or perhaps police) it all equally to what ever rate is required to offer the speed you purchase.I also don't understand what exactly you mean by "mask"?

author: AVGresponding
author_rank: Super Contributor
timestamp: June 12, 2020, 08:51:49 pm
content: Internet data packets have several layers of data.The "mask" being referred to is the IPv4 address the packet originates from. You can alter it to make it look like it came from somewhere else by changing the mask, which is what translates the intra addy to the outer one, sort of.I'm not the greatest at explaining this stuff...

author: TomS_
author_rank: Frequent Contributor
timestamp: June 13, 2020, 10:09:08 am
content: Quote from: AVGresponding on June 12, 2020, 08:51:49 pmI work as a network engineer, so I know how IP works.Im trying to understand what "mask" is supposed to mean, because that isnt terminology I am used to. Unless people are talking about "masquerading", which is terminology I have seen when using Linux as a router, but sounds like another way to say NAT.But I dont think Ive ever heard of any residential ISP classify different types of traffic and shape or police them differently on an individual service basis - that requires a lot of grunt in the BRAS or LNS. There have been discussions about doing that on a network-wide basis in the US, ala network neutrality, but thats a commercial play between network operators and content providers and not at all something intended to benefit the end user (except when the content provider agrees to pay the network operator to provision or allow more bandwidth to improve the end user experience). In my experience, ISPs will typically just count all traffic equally and shape or police your service to x speed. Maybe some niche ISPs do it... Would be interested to hear of any specific examples so I could look into it.So as I understand it, and I have built and run access level ISP networks and infrastructure in my time, simply using a VPN isnt going to somehow magically make you avoid what ever traffic shaping/policing your ISP implements. There are still IP packets coming from your broadband service which count towards what ever throughput quota your service is assigned.Otherwise, a VPN is just a VPN. Its not "masking" anything in any kind of special way, its just doing what a VPN does - encapsulate your traffic and encrypt it in transit to some other location. No different to a corporate VPN, just maybe with a slightly more user friendly interface wrapped around it. Any other suggestion is just marketing BS that all of these VPN companies come up with to justify their existence IMO.

author: madires
author_rank: Super Contributor
timestamp: June 13, 2020, 10:54:46 am
content: Changing the source IP address is called spoofing. Unless you're trying do DOS some service address spoofing won't help you much. If you change the source address the response will be sent to the spoofed address, not to you. So you won't be able to establish a TCP connection for example. Also some ISPs have anti-spoof filters in place.The term "mask" could relate to changing port numbers, e.g. running a VPN via TCP port 80 to make it look like HTTP. That's a common way to evade firewall rules. But if that traffic runs through an ALG (application layer/level gateway) or a DPI firewall it will be detected as non-HTTP and dropped.About traffic shaping / QoS I'd like to add that ISPs/telcos offering VoIP typically apply QoS rules to prioritize VoIP traffic. Any other traffic goes into the "best effort" queue. And there's another thing to know. Even without any QoS configuration carrier-grade routers prioritize network management and routing protocols, while everything else is "best effort".

author: AVGresponding
author_rank: Super Contributor
timestamp: June 13, 2020, 11:39:38 am
content: Spoofing isn't what I was intending to mean, I was referring to IPv4 masking that's used between an intranet and the internet to effectively increase the number of available addresses.

author: olkipukki
author_rank: Frequent Contributor
timestamp: June 13, 2020, 11:40:13 am
content: Quote from: steve30 on May 23, 2020, 08:50:10 amTheir 'Terms of Use' stated:redirected tohttps://amazingtechsale.com/intl/legal/term.php?prod=wifiultraboost&net=1005&variation=wifixQuoteMeanwhile 'Contact Us'...Quoteand a public print out from Estonia's company house leads tohttp://novads.co=>https://igadget24.comwith similar "superb" gadgets

author: TomS_
author_rank: Frequent Contributor
timestamp: June 13, 2020, 11:57:03 am
content: Quote from: madires on June 13, 2020, 10:54:46 amI find that an interesting statement. Routing protocols will indeedmarktheir traffic with some high priority (exactly which one escapes me right now, and my google foo is failing to find an answer quickly), but as I understand it, unless you actually configure QoS andacton those markings, those packets will just be pooled with all other traffic and effectively become BE like everything else.Ive been working primarily with optical networks and automation the last couple of years, so if something has changed then maybe Ive missed it...

author: madires
author_rank: Super Contributor
timestamp: June 13, 2020, 12:23:21 pm
content: Quote from: AVGresponding on June 13, 2020, 11:39:38 amThat's commonly called NAT.

author: madires
author_rank: Super Contributor
timestamp: June 13, 2020, 12:43:11 pm
content: Quote from: TomS_ on June 13, 2020, 11:57:03 amThe details differ based on each implementation, but generally speaking each interface has a set of queues for outgoing packets to make QoS work. Locally generated netmgt/routing specific packets are put into the high priority queue automatically without any QoS related configuration. It's simply the default action.Quote from: TomS_ on June 13, 2020, 11:57:03 amIt's an old feature.

author: OwO
author_rank: Super Contributor
timestamp: June 13, 2020, 12:49:47 pm
content: Getting a bigger share of the bandwidth is very easy, all you need to do is make TCP not back off as aggressively when there is packet loss. Your ISP never limits your *line rate*, which is how fast you are physically able to transmit packets. The way your ISP limits your speed is to drop packets above a certain data rate. However if you have not hit your speed cap (set by your subscription), you can usually get more packets through by transmitting more packets in the first place (the loss rate is constant). TCP does not help you with this; as soon as it sees packet loss it backs off the send rate.

author: madires
author_rank: Super Contributor
timestamp: June 13, 2020, 02:43:10 pm
content: Sorry, but your comment is contracting itself. If your ISP limits your throughput by a rate limit how would changing TCP's sliding window increase throughput (besides the protocol's efficiency)? In case of a hard rate limit any additional packet above the limit will be simply dropped. Most rate limit implementations also allow the configuration of bursts, i.e. allowing some packets more for a short period. But if you exceed those too, the additional packets will be dropped again. A prevalent problem of SOHO routers and WIFI APs is bufferbloat which conflicts with TCP's way of handling congestions. I have no idea how many vendors have added/enabled CoDel. It's supported by linux for a while.In the EU the customer's data throughput is usually limited by the line because it's simple to do and reduces load on the access routers. Rate-limiting on access routers with hundreds of subscribers is more expensive (resources). By line I mean the line profile used by the access technology, e.g. DSL, not the physical line. I can set a specific DSL profile in the DSLAM/MSAN to limit the throughput. Even if you run multiple PPPoE links over that DSL line you can't exceed the line's data throughput. And since DSL runs over telephone wire you also have less interference problems between lines when using limited DSL profiles instead of using the maximum possible. I don't know the reason why some ISPs prefer to rate-limit on access routers. At first glance it sounds like a bad idea.

author: TomS_
author_rank: Frequent Contributor
timestamp: June 13, 2020, 04:04:34 pm
content: Quote from: madires on June 13, 2020, 12:43:11 pmDefinitely seem to be the case. I had to go ask some other network friends, and they mostly said the same thing: depends on vendor/hardware/software and/or default settings.I feel like Ive been living a lie all of this time.

author: OwO
author_rank: Super Contributor
timestamp: June 13, 2020, 04:10:12 pm
content: Quote from: OwO on June 13, 2020, 12:49:47 pmI'm talking about the case of backbone packet loss, when you aren't getting the advertised speeds. In that case you can increase your throughput by adjusting TCP to tolerate higher packet loss.

author: TomS_
author_rank: Frequent Contributor
timestamp: June 13, 2020, 04:15:36 pm
content: Quote from: madires on June 13, 2020, 02:43:10 pmPrevious ISPs I have worked at also rate limited at the LNS/BRAS.If a customer is the receiver of some "unwanted attention", then without rate limiting at the BRAS/LNS, you'll end up forwarding potentially many gigabits/sec into your access network. If you also rate limit the customer session to the same as their downstream rate, then the BRAS/LNS just drops excess traffic.Doesnt really help the rest of your network, and is definitely more resource hungry, but saves your access network and the rest of the customers on it until you can blackhole the destination.

author: madires
author_rank: Super Contributor
timestamp: June 13, 2020, 06:15:03 pm
content: Quote from: OwO on June 13, 2020, 04:10:12 pmTime for some basics. TCP has a built-in mechanism to deal with packet loss and congestion. To ensure reliable packet transport the receiver acknowledges received packets. For more efficiency the receiver acknowledges several packets in a row by one ACK packet. The sender waits for the ACK and then sends the next batch of packets. If the sender doesn't receive ACKs within some timeout period he will retransmit the lost packets. The maximum number of un-acknowledged packets is controlled by the "sliding window" algorithm. With a low packet loss (no congestion) the window will be large. And with a high packet loss (congestion) the window size will be small. That way TCP adapts itself automatically to the available data rate / packet loss between sender and receiver.How would you adjust TCP to tolerate a higher packet loss?

author: AVGresponding
author_rank: Super Contributor
timestamp: June 13, 2020, 06:41:04 pm
content: Quote from: madires on June 13, 2020, 06:15:03 pmHit it with a hammer?

author: madires
author_rank: Super Contributor
timestamp: June 13, 2020, 06:58:50 pm
content: Quote from: TomS_ on June 13, 2020, 04:15:36 pmI don't see a real benefit. It might help to mitigate the impact of a tiny DoS, but with today's DDoS attacks there's so much traffic the access router's backhaul links will be totally congested and therefore impact all subscribers of that router anyway. However, DDoS attacks are handled at the edge of your network nowadays, and they can be huge. The largest ones are more than 1 Tbps.

author: OwO
author_rank: Super Contributor
timestamp: June 14, 2020, 04:47:26 am
content: Quote from: madires on June 13, 2020, 06:15:03 pmBy not using TCP in the first placeThe network connection from China to the rest of the world is horrific, packet loss averages 20% during the day and 50% in the evening (but much lower from 2am to 8am). TCP gives you about 20KB/s if you're lucky and completely unusable when you get into 50% packet loss. However, if you open many TCP connections you can get a few MB/s through, which just means file downloads (using a multithreaded downloader) get more bandwidth compared to interactive users.I've designed a custom stream transport protocol for point to point tunneling over high packet loss networks:https://gitlab.com/bepissneks/udptun/-/blob/master/udp_stream_transport.hppIt implements multiple streams in one connection, much like SCTP. There is no "sliding window" anymore, data chunks simply sit in a priority queue waiting to be sent, and a thread transmits packets from the queue at a constant rate (currently set at 100pkt/s or 150KB/s). Data chunks are individually ack'd so that only what is lost needs to be retransmitted (optimized for high packet loss conditions). A chunk that isn't ack'd after a timeout (determined by RTT) goes back onto the queue. A packet can contain many data chunks and many acks, so we don't have to send a new packet for every ack.The use case is you open one udptun connection to the server, listen for local tcp connections, and forward all tcp streams onto the udptun connection. The server side will then create tcp connections to the actual destination as new streams are created, and forward udptun streams to tcp streams. The proxy client/server here implements that:https://gitlab.com/bepissneks/udptun/-/blob/master/examples/proxy_client.cppThe send rate I'm using is 150KB/s, so it should not hog too much bandwidth, but in theory someone can turn it way up and get a big slice of the bandwidth pie, so I'm not going to document this software or release it in easily accessible form, (and you need to make deep code changes to change the send rate). That speed is good enough for web browsing and very low-fi youtube, but is still small compared to what a typical multithreaded downloader will use up.

author: Haenk
author_rank: Super Contributor
timestamp: June 14, 2020, 06:08:30 am
content: Quote from: olkipukki on June 13, 2020, 11:40:13 amThey really know what they are doing. If you are beginning to suffer from all that Wifi X radiation and too fast data streams from the interwebs, they also offerhttps://igadget24.com/intl_4/order.php?prod=radiationstopperpro- too bad, 5G isn't mentioned (Or is it? I did only look at the Pictures and didn't bother to read the text…)Honestly, if thsi does not support 5G blocking, this product is way outdated and should be offered at an massive discount. Greedy bastards.

author: madires
author_rank: Super Contributor
timestamp: June 14, 2020, 11:33:44 am
content: Quote from: OwO on June 14, 2020, 04:47:26 amI see, you are trying to work around the special situation in your country. AFAIK, the problem with high packet losses in China is caused by congestion (let's make more profit by spending less on the network) and also by the tons of middleboxes mangling IP traffic. It's half a wonder it's still working somehow.This might interest you:NANOG 79 - Characterizing Transnational Internet Performance and the Great Bottleneck of Chinahttps://storage.googleapis.com/site-media-prod/meetings/NANOG79/2192/20200601_Zhu_Characterizing_Transnational_Internet_v1.pdf

author: MrMobodies
author_rank: Super Contributor
timestamp: June 18, 2020, 05:19:10 pm
content: And looking at their picture showing a speedtest and I knew it was going to be a generic stock photo taken from somewhere.Taken from here:http://m.baoventd.org/soc-voi-nhung-quoc-gia-co-mang-di-dong-nhanh-hon-ca-wi-fi-80824.htmlhttps://translate.google.co.uk/translate?hl=en&sl=vi&u=http://m.baoventd.org/soc-voi-nhung-quoc-gia-co-mang-di-dong-nhanh-hon-ca-wi-fi-80824.html&prev=searchReviews have got to be fake.Look at this review:QuotePicture taken from a listing on Olx:https://www.olx.ua/obyavlenie/wi-fi-usilitel-signala-retranslyator-ripiter-IDHZRNh.html?sd=1#dcc8721e5c;promoted