Outside your house your isp drilled a hole and pushed a wire inside; it conects to something and it is not the TP-Link.
What device is that wire plugged into and it is NOT in your diagram.
1 Like
I'm sorry. I was not clear:
Please plug in the TP-Link, get it working and and then go the routers admin settings and get us what the Lan address is and the Wan Address and the Wan gateway.
How this information will help?
I don't think it's a good idea to show my ip.
There is definitely a DCHP server, I have a gateway, subnet mask and ip assigned for tp-link 720n.
Your network setup is unclear. They are requesting the primary ip to determine if it’s a private or public ip, if it’s a private ip that means there’s another router upstream.
Post your network layout and goals and we can help
Feel free to redact parts of the IP
1 Like
Ok, here is what i have
MAC: EC-08-6B-7E-E1-C9
IP: 100.103.132.103
Mask: 255.255.192.0
Gateway: 100.103.191.254
DNS-server: 109.195.144.3 , 5.3.3.3
the MAC belongs to a TP-Link device, not your RPi, the 100.103 IP is from a CGNAT range.
tried copying the TP-Links WAN MAC to your RPi ?
The ISP connection is Ethernet then. This is only practical in places such as a dorm or apartment house, since the maximum length of an Ethernet cable is 100 meters. The other end of the cable would be plugged into an Ethernet switch in the building at a central place connected to other apartments.
One thing to consider is that the WR720 has 100 Mb "Fast Ethernet" ports which only require two wire pairs in the cable. The Pi 4 has gigabit Ethernet which requires all four wire pairs in the cable. Trying to connect two Gigabit ports with two-pair cable is not supported by the standard and it may not work at all.
1 Like
ok, if you now connect the RPis ethernet port directly to whatever's in the other end (not the TP-Link), and use the console to ping something, does it still fail ?
then run logread -f on the console or via ssh, while you unplug, and reconnect the ethernet cable.
@frollic There was no output when i plug/unplug (tried waiting)
Here is some output when clicked restart wan interface in Luci.
root@OpenWrt:~# logread -f
Tue Nov 14 13:48:59 2023 daemon.notice netifd: Interface 'wan' is disabled
Tue Nov 14 13:48:59 2023 daemon.notice netifd: Interface 'wan' is enabled
Tue Nov 14 13:48:59 2023 kern.info kernel: [ 113.684411] bcmgenet fd580000.ethernet: configuring instance for external RGMII (RX delay)
Tue Nov 14 13:48:59 2023 kern.info kernel: [ 113.692969] bcmgenet fd580000.ethernet eth0: Link is Down
One thing I noticed right now is that eth0 port on raspberry does not blink as it was blinking when plugged in tp-link.
the RPi doesn't detect any link on the port ... question is why.
1 Like
output from "logread -f" of raspberry when it was connected to tp-link (working version) and then uplugged / plugged back.
Mon Jan 29 14:44:52 2024 daemon.notice netifd: Network device 'eth0' link is down
Mon Jan 29 14:44:52 2024 daemon.notice netifd: Interface 'wan' has link connectivity loss
Mon Jan 29 14:44:52 2024 kern.info kernel: [ 843.620488] bcmgenet fd580000.ethernet eth0: Link is Down
Mon Jan 29 14:44:52 2024 daemon.notice netifd: wan (1242): udhcpc: received SIGTERM
Mon Jan 29 14:44:52 2024 daemon.notice netifd: wan (1242): udhcpc: unicasting a release of 192.168.0.105 to 192.168.0.1
Mon Jan 29 14:44:52 2024 daemon.notice netifd: wan (1242): udhcpc: sending release
Mon Jan 29 14:44:52 2024 daemon.notice netifd: wan (1242): udhcpc: entering released state
Mon Jan 29 14:44:52 2024 daemon.notice netifd: wan (1242): Command failed: ubus call network.interface notify_proto { "action": 0, "link-up": false, "keep": false, "interface": "wan" } (Permission denied)
Mon Jan 29 14:44:52 2024 daemon.notice netifd: Interface 'wan' is now down
Mon Jan 29 14:44:52 2024 daemon.warn dnsmasq[1]: no servers found in /tmp/resolv.conf.d/resolv.conf.auto, will retry
# plugged now
Mon Jan 29 14:47:21 2024 daemon.warn odhcpd[931]: No default route present, overriding ra_lifetime!
Mon Jan 29 14:47:25 2024 daemon.notice netifd: Network device 'eth0' link is up
Mon Jan 29 14:47:25 2024 daemon.notice netifd: Interface 'wan' has link connectivity
Mon Jan 29 14:47:25 2024 daemon.notice netifd: Interface 'wan' is setting up now
Mon Jan 29 14:47:25 2024 kern.info kernel: [ 996.501523] bcmgenet fd580000.ethernet eth0: Link is Up - 100Mbps/Full - flow control rx/tx
Mon Jan 29 14:47:25 2024 daemon.notice netifd: wan (2385): udhcpc: started, v1.36.1
Mon Jan 29 14:47:25 2024 daemon.notice netifd: wan (2385): udhcpc: broadcasting discover
Mon Jan 29 14:47:25 2024 daemon.notice netifd: wan (2385): udhcpc: broadcasting select for 192.168.0.105, server 192.168.0.1
Mon Jan 29 14:47:25 2024 daemon.notice netifd: wan (2385): udhcpc: lease of 192.168.0.105 obtained from 192.168.0.1, lease time 7200
Mon Jan 29 14:47:25 2024 daemon.notice netifd: Interface 'wan' is now up
Mon Jan 29 14:47:25 2024 daemon.info dnsmasq[1]: reading /tmp/resolv.conf.d/resolv.conf.auto
Mon Jan 29 14:47:25 2024 daemon.info dnsmasq[1]: using nameserver 109.195.144.3#53
Mon Jan 29 14:47:25 2024 daemon.info dnsmasq[1]: using nameserver 5.3.3.3#53
Mon Jan 29 14:47:25 2024 daemon.info dnsmasq[1]: using only locally-known addresses for test
Mon Jan 29 14:47:25 2024 daemon.info dnsmasq[1]: using only locally-known addresses for onion
Mon Jan 29 14:47:25 2024 daemon.info dnsmasq[1]: using only locally-known addresses for localhost
Mon Jan 29 14:47:25 2024 daemon.info dnsmasq[1]: using only locally-known addresses for local
Mon Jan 29 14:47:25 2024 daemon.info dnsmasq[1]: using only locally-known addresses for invalid
Mon Jan 29 14:47:25 2024 daemon.info dnsmasq[1]: using only locally-known addresses for bind
Mon Jan 29 14:47:25 2024 daemon.info dnsmasq[1]: using only locally-known addresses for lan
Mon Jan 29 14:47:25 2024 user.notice firewall: Reloading firewall due to ifup of wan (eth0)
Mon Jan 29 14:47:25 2024 daemon.info dnsmasq[1]: using nameserver 5.3.3.3#53
Mon Jan 29 14:47:25 2024 daemon.info dnsmasq[1]: using only locally-known addresses for test
output from tp-link logs when green wire in it's wan port
|INFO 2006-01-01 08:02:01|DHCPC: Network config succeeded.|
|INFO 2006-01-01 08:02:00|DHCP client read, totlen = 368(1048).|
|INFO 2006-01-01 08:02:00|DHCP client tx request.|
|INFO 2006-01-01 08:02:00|DHCP client read, totlen = 368(1048).|
|INFO 2006-01-01 08:02:00|DHCP client tx discover(B).|
I've conducted speed test and my working version with raspberry AP I have speed x4 compared to tp-link 720.
This is already good for my needs and the only thing that I hate is some proprietary peace of hardware/software in my house. 
have you got a dumb switch ?
try putting it between the RPi and the wire going to the ISP.
you could also try playing with ethtool, forcing a link on the RPis ethernet port.
2 Likes
I don't a switch((
force link does not give any effect.
Where should I look in ethtool?
I've conducted an experiment: connected wan port of tp-link to raspberry and set up a dhcp server on it.
After checking /tmp/dhcp.leases, i found a hostname of tp-link. Here you can see that MAC is the same.
ec:08:6b:7e:e1:c9 192.168.1.195 WR720N
Then in wan settings used override hostname:
No luck unfortunately ((
If the carrier doesn't come on there's no data transmission possible, there is nothing that software can do.
You could press your old 720 into service as a switch by turning off the DHCP server in the stock firmware, then plug one LAN port into the "green cable" wall Ethernet outlet and another LAN port to the Pi. Do not connect anything to the wan port. This is simply going to hardware bridge between the ports (at 100 Mb).
1 Like
Yes you do, you just do not think of it as a switch.
Plug the TP--Link using only the yellow lan ports:
Plug the ISP ethernet into a lan port and the pi into a lan port..
There should be some blinking on both ports; not that its is going to work and get you internet, but it is a switch.
Sorry, I just saw this.
@mk24 @LilRedDog
Wow I really don't think this way)))
And it is working now.
Wed Jan 31 10:50:35 2024 daemon.notice netifd: wan (10479): udhcpc: unicasting a release of 100.103.163.22 to 109.195.144.70
Wed Jan 31 10:50:35 2024 daemon.notice netifd: wan (10479): udhcpc: sending release
Wed Jan 31 10:50:35 2024 daemon.notice netifd: wan (10479): udhcpc: entering released state
Wed Jan 31 10:50:35 2024 daemon.notice netifd: wan (10479): Command failed: ubus call network.interface notify_proto { "action": 0, "link-up": false, "keep": false, "interface": "wan" } (Permission denied)
Wed Jan 31 10:50:35 2024 daemon.notice netifd: Interface 'wan' is now down
Wed Jan 31 10:50:35 2024 daemon.notice netifd: Interface 'wan' is setting up now
Wed Jan 31 10:50:35 2024 daemon.info dnsmasq[1]: reading /tmp/resolv.conf.d/resolv.conf.auto
Wed Jan 31 10:50:35 2024 daemon.info dnsmasq[1]: using nameserver 1.1.1.1#53
Wed Jan 31 10:50:35 2024 daemon.info dnsmasq[1]: using nameserver 8.8.8.8#53
Wed Jan 31 10:50:35 2024 daemon.info dnsmasq[1]: using only locally-known addresses for test
Wed Jan 31 10:50:35 2024 daemon.info dnsmasq[1]: using only locally-known addresses for onion
Wed Jan 31 10:50:35 2024 daemon.info dnsmasq[1]: using only locally-known addresses for localhost
Wed Jan 31 10:50:35 2024 daemon.info dnsmasq[1]: using only locally-known addresses for local
Wed Jan 31 10:50:35 2024 daemon.info dnsmasq[1]: using only locally-known addresses for invalid
Wed Jan 31 10:50:35 2024 daemon.info dnsmasq[1]: using only locally-known addresses for bind
Wed Jan 31 10:50:35 2024 daemon.info dnsmasq[1]: using only locally-known addresses for lan
Wed Jan 31 10:50:35 2024 daemon.notice netifd: wan (13146): udhcpc: started, v1.36.1
1 Like