|
Buff Hardback posted:This isn't going to work (at least without headaches). I'm a bit fuzzy on what you're connecting where, but the AT&T copper can't be running through an AP to get from the ONT to the gateway. I'm not sure what you mean by the AT&T copper, but I can see that maybe it wouldn't work to have anything between the ONT and their gateway. Could I put their gateway next to the ONT, then go out their gateway to the Dream Machine? fletcher posted:I found the signal from the In-Wall units was a lot worse than the FlexHD's, I ended up returning the In-Wall APs. I liked the aesthetic of them and not having to stick a big thing on the wall, but the signal from the FlexHD was just so much better. Otherwise, it sounds good to me. Are you adding these drops? If I could do ceiling drops I would probably rather have a ceiling mount APs. How good of a wireless AP is the Dream Machine? I might be able to get away with one in-wall unit plus the Dream Machine if I put that in the same place as the ONT and AT&T's gateway. As for ceiling drops, they'd be easy upstairs because of the attic, but probably not so much downstairs.
|
#
?
Jan 2, 2021 03:59
|
|
|
|
| # ? May 29, 2024 19:00 |
|
|
hooah posted:Is this a reasonable setup? The ISP's ONT would have to connect to the switch via one of the in-wall APs since I don't think AT&T will very conveniently change the location of their equipment. Your setup seems fine (although see that comment about InWall HDs... which I didn't know and now am sad about). If you are having drops done AND/OR you cannot move the ONT location either: * Move the UDM to that location, near the ONT * Have an extra cable run from the ONT location to the UDM location - connect the ONT to the UDM's WAN port using that cable hooah posted:How good of a wireless AP is the Dream Machine? I'm using it right now and it's fairly solid. Depends how you define "good". Everything seems fine for my condo wide use.
|
|
#
?
Jan 2, 2021 04:09
|
|
|
Happy 2021 Internet connection fell over this morning. ATT Fiber RG bypass is no longer working for me. Seems that as ATT deploys network upgrades; the newer setup can't be bypassed with the old tricks, so many of you may encounter this at some point too. Here's to hoping someone figures it out soon. In the meantime I'll rock the double NAT and test the session table on the BGW210 
|
|
#
?
Jan 2, 2021 05:00
|
|
|
SlapActionJackson posted:Happy 2021 Why not just use the dmz/pass through mode? Doesn't that avoid double NAT?
|
|
#
?
Jan 2, 2021 05:04
|
|
|
withoutclass posted:Why not just use the dmz/pass through mode? Doesn't that avoid double NAT? Sort of. The RG still tracks all sessions that flow through it; it just does not have to re-write the addresses since the 2nd router is already using the WAN IP. It's not a true bridge mode. It will avoid double NAT trouble for e.g UPnP, though.
|
|
#
?
Jan 2, 2021 05:16
|
|
|
SlapActionJackson posted:Sort of. The RG still tracks all sessions that flow through it; it just does not have to re-write the addresses since the 2nd router is already using the WAN IP. It's not a true bridge mode. That's good to know, I figured it was a real passthrough butt I should've known better. I've been using it this way for a year or so now without issues so I'm sure you'll be ok.
|
|
#
?
Jan 2, 2021 05:56
|
|
|
SlapActionJackson posted:Happy 2021 RG bypass? I'm using a dumb switch bypass and it's working fine still.
|
|
#
?
Jan 2, 2021 06:16
|
|
|
Residential Gateway. I was using proxy_eap which worked brilliantly, but now my USG can't get a dhcp lease from the WAN. I don't know if the dumb switch bypass still works on the upgraded network, but since it can't auto-recover from a power outage, I think I'll take my chances with IP Passthrough mode for a while.
|
|
#
?
Jan 2, 2021 06:56
|
|
|
hooah posted:I'm not sure what you mean by the AT&T copper, but I can see that maybe it wouldn't work to have anything between the ONT and their gateway. Could I put their gateway next to the ONT, then go out their gateway to the Dream Machine? I would think that should be fine quote:How good of a wireless AP is the Dream Machine? I might be able to get away with one in-wall unit plus the Dream Machine if I put that in the same place as the ONT and AT&T's gateway. The wireless in the UDM seems pretty good, definitely better than the in-walls from my experience
|
|
#
?
Jan 2, 2021 06:59
|
|
|
SlapActionJackson posted:Residential Gateway. I was using proxy_eap which worked brilliantly, but now my USG can't get a dhcp lease from the WAN. I don't know if the dumb switch bypass still works on the upgraded network, but since it can't auto-recover from a power outage, I think I'll take my chances with IP Passthrough mode for a while. Yeah that is the main downside of the dumb switch bypass, could get a UPS but  Hopefully it still works on the upgraded, fingers crossed I'm already on it. Not sure why att is so anal about making people use their lovely modems anyhow. If you just want the 10$ then just ignore peeps bypassing it, and take their money anyhow. poo poo I would pay then 10$ to not have to use the drat thing.
|
|
#
?
Jan 2, 2021 07:25
|
|
|
Probably because they want their remote tech support to have some level of access to your network for doing poo poo like resetting the gateway.
|
|
#
?
Jan 2, 2021 14:23
|
|
|
I posted awhile ago about this issue. What are the troubleshooting steps for a device not connecting to the internet through my AP? In this case, a Samsung A7 and my TP-Link AC1750v2. Used to have a pihole running a DNS ad blocker but that’s been taken out of the loop recently so I don’t think it’s the DNS settings on the router, that’s just 1.1.1.1 and 1.0.0.1 now. We’ve tried: Resetting all involved devices Assigning a static IP to the device (and ARP binding for kicks) Setting dns settings in the device To add to the fun, this friend uses the same router but the V5 one at home and it works great. What else should I try and why does this happen with some Samsung stuff and this router?
|
|
#
?
Jan 2, 2021 15:00
|
|
|
SlapActionJackson posted:Happy 2021 Well, poo poo. I wonder if their new BGWs are any better, apparently they have a multi-gig ethernet port on em so who knows. Edit: according to the wizards at dslreports it's actually worse, the new ones are integrated ONT and gateway so you can't do the bypass trick. Doesn't appear to have true bridge mode either. H2SO4 fucked around with this message at 18:08 on Jan 2, 2021 |
|
#
?
Jan 2, 2021 15:48
|
|
|
withoutclass posted:Probably because they want their remote tech support to have some level of access to your network for doing poo poo like resetting the gateway. Bingo. Att have always been fuckwits with the proprietary cpe. They also refuse to support cablecards for TV. Frontier finger points my router any time I have an issue because they can't run their speed test from the overpriced poo poo box they want me to pay for.
|
|
#
?
Jan 2, 2021 18:02
|
|
|
H110Hawk posted:
Frontier does use some real poo poo boxes too.. My parents have had their VDSL service (called frontier vantage) for 2 years now. They are on their 5th modem/router. Every couple months they just up and die.
|
|
#
?
Jan 2, 2021 21:03
|
|
|
Aaaaaaaaaaaand of course my IPv6 subnetting broke because now I can't get a /60 with the drat RG in the way. It will hand out 8 /64s (but not a /61, /62, or /63  jfc ATT)In case it helps anyone, I did figure out how to get the USG to make multiple PD requests to hand out to subnets: 1. In the controller, configure the WAN for ipv6 and a /64 request. Enable one subnet with ipv6-pd. This is the only one you can configure through the GUI. Disable ipv6 on your other subnets. 2. In your config.gateway.json add these sections On the WAN interface add a pd object for each subnet you want to have ipv6. Each pd object will make an upstream request and delegate the returned prefix to the specified interface (which is LAN.VLAN) code:code:
|
|
#
?
Jan 3, 2021 00:39
|
|
|
If any of you have zyxel equipment, time to security scramble https://www.zdnet.com/article/backdoor-account-discovered-in-more-than-100000-zyxel-firewalls-vpn-gateways/ They have a plaintext password root backdoor account in a ton of their products
|
|
#
?
Jan 3, 2021 01:10
|
|
|
Azhais posted:If any of you have zyxel equipment, time to security scramble Man, not surprising at all and I know exactly why and how it happened... some day, embedded hardware/software teams will have management (technical and programmatic) that are not complete loving twats.
|
|
#
?
Jan 3, 2021 06:05
|
|
|
tuyop posted:I posted awhile ago about this issue. What are the troubleshooting steps for a device not connecting to the internet through my AP? I assume other devices can access the router fine, right? A quick search turned up this page that goes through Samsung A7 troubleshooting from the obvious to less obvious, so maybe it can help? https://thedroidguy.com/fix-samsung-galaxy-a7-cannot-access-internet-wi-fi-network-troubleshooting-guide-1079557
|
|
#
?
Jan 3, 2021 07:27
|
|
|
CaptainSarcastic posted:I assume other devices can access the router fine, right? Oh yeah, everything else works fine with the router, from smart bulbs to raspberry pi’s to Windows and Mac laptops. I had another friend with a Samsung phone that had a lot of trouble with our router as well so I’m assuming it’s their specific chipset or whatever, but I’ll look into that next time, thanks!
|
|
#
?
Jan 3, 2021 07:48
|
|
|
I've set up Jool for NAT64 and am redirecting my PiHole to the DNS64 servers of Cloudflare, to attempt running an IPv6 only network. Wish me luck! --edit: Steam already broke, so much for that 
Combat Pretzel fucked around with this message at 16:29 on Jan 3, 2021 |
|
#
?
Jan 3, 2021 16:23
|
|
|
SlapActionJackson posted:Sort of. The RG still tracks all sessions that flow through it; it just does not have to re-write the addresses since the 2nd router is already using the WAN IP. It's not a true bridge mode. I’m not quite sure I follow all the issues here. I have a Unifi setup and am moving to a place where I will have AT&T Fiber. If all I really care about is plugging poo poo in and having internet work, and not any “advanced” features will I run into any trickle?
|
|
#
?
Jan 3, 2021 17:29
|
|
|
ScooterMcTiny posted:I’m not quite sure I follow all the issues here. I have a Unifi setup and am moving to a place where I will have AT&T Fiber. If all I really care about is plugging poo poo in and having internet work, and not any “advanced” features will I run into any trickle? If you get a BGW you just use passthrough mode and it's fine.
|
|
#
?
Jan 3, 2021 17:44
|
|
|
withoutclass posted:If you get a BGW you just use passthrough mode and it's fine. Where is this setting accessible? On the web interface?
|
|
#
?
Jan 3, 2021 17:53
|
|
|
Hey thread, I was pointed in this direction from the Plex thread. Server is HP ProDesk with i5-6500 16GB ram and 1050ti. Clients are Nvidia Shield Tube 2019, Sony X900h and gaming desktop with Ryzen 3600 and 3080 How do I solve what seems to be bad peering from my server to the clients? Server ISP is Bell with fibre gig up, and I (client) have Rogers gig down. Everything is wired. Server is gigabit wired directly to Home Hub 3000 modem/router, clients are all wired to Asus RT-AX58U with gigabit. I ran iPerf and got 13.9 MBs which explains a lot, like stuttering on files greater than 8-10 Mbps. I've made sure none of the network configs on either end are borked but I know very little about networking tbh. iPerf test:  Bell ISP to closest Rogers ISP server available, in New Brunswick  Bell ISP to Bell ISP in New Brunswick 
|
|
#
?
Jan 3, 2021 19:27
|
|
|
Oysters Autobio posted:So I finally got around to dealing with this by installing the new router (TP-Link AC1750) I bought. Hi, just bumping this one because I didn't include a few important details: - I've tested out Modem direct to computer on the old router without the switch and was having the same results. So, just to summarize so far: Problem: Wired ethernet to PC internet not achieving ISP-rated speeds (200-300mpbs) Setup and Configuration: Modem: TP-link TC7650 Router: TP-Link Archer C7 AC1750 NIC: Intel Gigabit CT PCI-E Network Adapter EXPI9301CTBLK Switch: Gigabit 5-port TP-Link TL-SG1005D Cables: CAT6 Configuration: CAT6 through Modem - > Wireless Router - > Gigabit Switch -> PC ( into Intel NIC). Currently getting speeds (Speedtest.net and Google speed tests) of around 20mpbs. Summary - Old router (TP-Link Archer C5 AC1200) wasn't achieving ISP-rated speeds when directly connected via ethernet to PC - Got new Ethernet Card, no changes. - Very helpful ISP technical support ran multiple tests and discovered no ISP-side issues. - Discovered that Ethernet port on the old router was actually only rated for 100mpbs - Ordered new router that had advertised gigabit ethernet ports (TP-Link Archer C7 AC1750) - Still having the same speed issues, and duplication of troubleshooting problems that still point to the router being the issue despite having a new router. Troubleshooting done CAT6 through Modem -> Gigabit Switch -> PC (tested with both Intel NIC and mobo ethernet port). Results: 200-250mpbs speeds. CAT6 through Modem -> PC via Intel NIC and mobo ethernet port. Results: 200-250mpbs CAT6 through Modem - > Old Wireless Router -> PC (both ports). Results: 20-90mpbs CAT6 through Modem -> New Wireless Router -> PC (both ports). Results: 20-50mpbs CAT6 through Modem -> Gigabit Switch -> New Wireless Router -> PC (both ports). Results: 20-50mpbs I've also tried switching out the CAT6 cables and had no discernable differences. So what else could this be? All signs point to once again the router being the issue, even though this is a new router and one with advertised gigabit ports. Oysters Autobio fucked around with this message at 19:56 on Jan 3, 2021 |
|
#
?
Jan 3, 2021 19:52
|
|
|
hooah posted:Where is this setting accessible? On the web interface? Yep. If you're having a tech come, just tell them what you want to do and they'll help you out. That's what I did when I first got my install and didn't realize I'd be forced to use their gateway.
|
|
#
?
Jan 3, 2021 19:54
|
|
|
Penpal posted:Hey thread, I was pointed in this direction from the Plex thread. Are those speed tests being run from your Plex server? Have you checked to make sure your server NIC is negotiating at 1gb and not 100mb? [Edit: I guess what I am trying to get at is, are you seeing this issue on your LAN as well, or only over the Internet? I can get poo poo speeds to any number of speed test locations near me, so I just want to make sure we're troubleshooting the correct problem.] Internet Explorer fucked around with this message at 20:03 on Jan 3, 2021 |
|
#
?
Jan 3, 2021 19:55
|
|
|
Penpal posted:Hey thread, I was pointed in this direction from the Plex thread. If it's a peering issue my longtime experience in the ISP industry will have you complaining to your ISP which in turn will have them blaming the other ISP and advising you to contact them. The other guy will point the finger back to YOUR ISP and say it's YOUR ISP's fault. I spent far too much of my time and energy trying to explain these issues to people because peering agreements are generally NDA and privately arranged between the two companies. Since the paths you take to get to the target and back are likely different, you need a traceroute from you to the target showing all hops and a traceroute from the target to your endpoint to determine where the actual cause of the latency is occurring. Sometimes it's not bad peering, but rather an underperforming node on either network, or in some cases a third network you didn't know was there. Armed with this information you can plead your case. If the latency happens at the peering point on the trace from you to the target it could mean the return path has a congestion issue in some cases. It's best to get the entire pictures. IPerf isn't going to show you this information. The only thing we know right now is that you get lovely speeds when going to his ISP and quality speeds within your own. Get the traceroutes and post them so we can take a look and diagnose the point of failure.
|
|
#
?
Jan 3, 2021 19:56
|
|
|
Oysters Autobio posted:Hi, just bumping this one because I didn't include a few important details: This shouldn’t matter at these speeds (<500mbps) but is there anything like QoS enabled on the routers? That is typically done in software and it’s CPU intensive for even modest loads. Other thing to check is ensuring the speed your PC is negotiating with the router. That is, are you getting 100mbps or 1Gbps?
|
|
#
?
Jan 3, 2021 20:05
|
|
|
Internet Explorer posted:Are those speed tests being run from your Plex server? Speed tests were done from the server. And I ran the iPerf server (-s) from that machine as well. Server NIC is set to 1gb. The client is me, and I also run the server - I just moved it to my parents place because they have gigabit up/down and I have gigabit down but a lazy river 30 mbps up and I thought that would be the wisest move. These are the server's NIC Intel I219-LM settings: Adaptive Inter-Frame Spacing: Disabled Energy Efficient Ethernet: Off Row Control: Disabled Gigabit Master Slave Mode: Auto Detect Interrupt Moderation: Disabled Interrupt Moderation Rate: Off IPv4 Checksum Offload: RX and Tx Enabled Jumbo Packet: Disabled Large Send Offload V2 (IPv4): Disabled Large Send Offload V2 (IPv6): Disabled Legacy Switch Compatibility Mode: Disabled Locally Administered Address: Null? Log Link State Event: Disabled Max Number of RSS Queues: 2 Queues Packet Priority & VLAN: Enabled Protocol ARP Offload: Enabled Protocol NS Offload: Enabled PTP Hardware Timestamp: Disabled Receive Buffers: 256 Receive Side Scaling: Enabled Reduce Ink Speed during system idle: Disabled Software Timestamp: Disabled Speed & Duplex: 1.0 Gbps Full Duplex TCP Checksum Offload (IPv4): Disabled TCP Checksum Offload (IPv6): Disabled Transmit Buffers: 512 UDP Checksum Offload (IPv4): Disabled UDP Checksum Offload (IPv6): Disabled Ultra Low Power Mode when cable is disconnected: Enabled Wait for Link: Auto Detect Wake on Link Settings: Disabled Wake of Magic Packet: Enabled Wake on Magic Packet from off state: Enabled Wake on Pattern Match: Enabled I will figure out how to run a traceroute and see what it reveals. fake edit: and just to be clear, the speedtests above aren't local, they are to a node in another province, speedtest.net only showed one Roger server to ping so I assumed that would be the node it would jump through to get to me. The Bell ISP gets pretty much close to the 1gb up/down if the speedtest goes to the default server. I don't know if this info matters much
|
|
#
?
Jan 3, 2021 20:10
|
|
|
Penpal posted:Speed tests were done from the server. And I ran the iPerf server (-s) from that machine as well. This is helpful, thank you. I agree that it's a peering issue with your ISPs. The advice to run some traceroutes is a good one. Unfortunately, this isn't something you'll likely have good luck in getting an ISP to fix. How long has it been having this problem? Did it work correctly before then?
|
|
#
?
Jan 3, 2021 20:15
|
|
|
Internet Explorer posted:This is helpful, thank you. The issue has been prevalent since I moved the server to their place. Before I was just running the Plex server off of my gaming PC and using it locally, which worked perfectly - but I just came into a retired work PC, a Prodesk with decent specs, so I slapped a leftover video card into it and decided to make that machine my plex server and keep it at the parents, where they have great upload speeds and much more space than my apartment. My clients (mostly me) can direct play almost everything so I didn't think there would be an issue because it would just be sending out the files without much or any transcoding actually needed. I just did some traceroutes: From Bell server to my Rogers desktop:  From my Rogers desktop to Bell server:  I have no idea how to interpret this information tbh. fake edit: Just did some reading, doesn't seem like anything here is too out of order? forest spirit fucked around with this message at 20:45 on Jan 3, 2021 |
|
#
?
Jan 3, 2021 20:41
|
|
|
Penpal posted:The issue has been prevalent since I moved the server to their place. Before I was just running the Plex server off of my gaming PC and using it locally, which worked perfectly - but I just came into a retired work PC, a Prodesk with decent specs, so I slapped a leftover video card into it and decided to make that machine my plex server and keep it at the parents, where they have great upload speeds and much more space than my apartment. My clients (mostly me) can direct play almost everything so I didn't think there would be an issue because it would just be sending out the files without much or any transcoding actually needed. Depending on geographical distance, everything here looks in order. ~40ms latency isn't terrible for streaming and I've had people streaming at long distances from my server with no problems. Run your IPerf tests using UDP rather than TCP and see what you get for results. I've seen dramatic differences between the two over distances. Cross country we couldn't even get close to 100Mbps under TCP, switched to UDP and filled the pipe completely. I'm wondering if there is still some contention somewhere. What is the geographic distance between the two locations? edit: just noticed, nearly 100ms latency. That could be bad. You may be having a lot of TCP retransmits on the path. Again, try the UDP iperf test. Nulldevice fucked around with this message at 21:02 on Jan 3, 2021 |
|
#
?
Jan 3, 2021 20:59
|
|
|
None of the tests I can think of that you'd easily have access to in your situation will be hugely definitive, but if the root problem really is ISP-to-ISP network bottlenecks - you're mostly hosed. Run the speed tests between your server and a cellular network - assuming your phone/tethered network is capable of enough speed to show an improvement over what your tests already show. Connect to a VPN and then run the speed tests over that VPN. Again, assuming your VPN itself is not the bottleneck. This way your client traffic uses whatever routes Rogers has to your VPN provider and then from your VPN provider to Bell, which would most likely be different than the routes you get directly from Rogers to Bell. The other possibility is that one of the ISPs is using traffic shaping and running your traffic through a VPN puts it in a different category that isn't getting hosed as hard. If the root cause is either of the last two - bad route or filtering - then using a VPN is a far more viable solution than getting ISPs to acknowledge they're doing something lovely to a residential user. If it's literally just being filtered at some level then you at least could just use a roll-your-own VPN solution between the two points instead of bringing in a third party. IOwnCalculus fucked around with this message at 21:04 on Jan 3, 2021 |
|
#
?
Jan 3, 2021 21:02
|
|
|
IOwnCalculus posted:None of the tests I can think of that you'd easily have access to in your situation will be hugely definitive, but if the root problem really is ISP-to-ISP network bottlenecks - you're mostly hosed. True as one of many possibilities, but his iperf tests showing direct connection between the two devices are showing average of 13Mb/s. I've seen this behavior on cross country links with less latency than this using TCP. Testing using UDP (since UDP gives no fucks if it gets there or not) floods the connection and will show a more true result of actual bandwidth. It's worth testing first before going through more strenuous steps as the software is already on both machines. I'd say run this test first and see what shakes out. The high latency is definitely going to mess with TCP streams such as Plex. I've seen private links with nothing on them unable to break 10Mb/s with TCP traffic across the US. When switched to UDP for the same test, it maxed out the line.
|
|
#
?
Jan 3, 2021 21:12
|
|
|
I just tried running ExpressVPN on my server and Plex could no longer connect remotely, I figured as much. I turned on the VPN on my client side and connected to the server but there was still stuttering, so it's definitely on the server/bell side. If I could only get Bell in my building, I assume I wouldn't even have this issue. Server connected to VPN speedtest to local server ISP (so the usual connection the server is coming from)  Server connected to VPN to closest rogers server/node:  edit: Just read the replies/edits above my post. What else would I need to do to figure this out, I have no experience troubleshooting anything network related. And I'm certain Express VPN isn't going to be the best choice for this. forest spirit fucked around with this message at 21:22 on Jan 3, 2021 |
|
#
?
Jan 3, 2021 21:20
|
|
|
rufius posted:This shouldn’t matter at these speeds (<500mbps) but is there anything like QoS enabled on the routers? That is typically done in software and it’s CPU intensive for even modest loads. QOS is not enabled. Should it be? Additionally, according to the adapter settings, it says I'm at 1gpbs. Is there another specific way I should be checking the negotiating speed?
|
|
#
?
Jan 3, 2021 21:54
|
|
|
Penpal posted:I just tried running ExpressVPN on my server and Plex could no longer connect remotely, I figured as much. I turned on the VPN on my client side and connected to the server but there was still stuttering, so it's definitely on the server/bell side. Try this with iperf: client side: iperf -u -b 100M -c <target.host.name> to your client, and add iperf -s -u to your server side. Customize any port settings if needed. If you get the full 100Mb/s, increase to 200M and retry. Keep increasing until you hit a wall.
|
|
#
?
Jan 3, 2021 22:28
|
|
|
|
| # ? May 29, 2024 19:00 |
|
|
A Ubiquiti Dream Machine would render my Edgerouter X completely unnecessary, right?
|
|
#
?
Jan 3, 2021 22:39
|
|