If you replace the PS with your PC instead, does it still work?
Let's look at the IP address information on the PC in the situation where it does work and compare that against what you see when it doesn't work. Additionally, let's see the output (from the PC) of these ping tests (most relevant/interesting when it isn't working):
No 100% not a faulty cable I’ve tested cable on multiple devices works fine , also I tried swapping using the on board Ethernet and the usb to Ethernet connected to the router still won’t work
You're not showing tcpdump, but ifconfig. Please get familiar with tcpdump; you will need to be able to interpret tcpdump traffic.
From the looks of it, your bridge seems to be kind of working. The number of rx packets on one eth is close to the tx number on the other, which indicates the traffic entering on one side is going out the other side.
Now you need to inestigate the traffic.
Could you please stop posting photos of your monitor but proper text output, please? Maybe use the Wi-Fi of the Pi as an access point so you can connect to your Pi via SSH before you’re plug in your network cables.
Sorry wrong picture but it shows my WAN ip , ARP shows ONT is requesting to receive a reply from A specific MAC address and nothing else . Only thing I can think of is MAC locked but problem is when I setup my network I used the router provided by ISP and then changed to a 3rd party router and never had no issues
You need to figure out if the Pi is either swallowing some packages (which can happen in both directions) or modifying them. You’re doing this by comparing the traffic on eth0 with the traffic on eth1.
If here’s no difference between eth0 and eth1 on the Pi, you need to set up tcpdump on a computer which you connect to eth1 of the Pi, and compare eth0 of the Pi with the eth of the other computer.
A couple of hour ago, you claimed “ONT > Pi > Router > Playstation” fails but “ONT > router > pi > PlayStation” works.
So figure out how the Pi bridge alters the traffic. Regular bridges don’t, any traffic between Router and ONT should be absolutely unaltered when going through the Pi bridge device. No MAC address of the Pi should be at play, the Pi does not change the MAC address of packges in transit while in bridge mode. If it did, you’d see it when comparing tcpdump of eth0 with tcpdump of eth1 on the Pi. That’s why I suggested you try tcpdump and understand what tcpdump is doing.
Since the behaviors you are experiencing don't appear to fit the logic that we would expect, my recommendation would be to start from scratch.
Start by generating a custom image that is just the standard 24.10.2 with the addition of the USB-ethernet driver, then write that to a card.
Insert the card, plug in the USB ethernet driver, power up the Pi, and plug your computer into the built-in ethernet port. Your computer should get an address in the 192.168.1.0/24 network.
Next, add eth1 to br-lan (if the system has auto-created new interfaces (wan/wan6) using eth1, just delete those).
Reboot the Pi, keeping your computer connected to the built-in ethernet port. Once the Pi has finished booting, you should, once again, have an IP address from Pi and you should be able to reach it (ping, ssh, LuCI web interface). Once that is confirmed, unplug the cable from the built-in ethernet port and connect it to the USB-ethernet adapter. Does your computer get an IP from the Pi at this point, and can it reach it normally?
Ok so I found this using TCPDump , I am seeing a lot more activity than before as I made a couple changes but still can’t seem to find the root cause nevertheless I’m making progress
relayd is not really intended for this purpose. Please do not complicate the situation; a bridge should just work as a bridge and it's not working as expected. That's why I recommend starting with the very basic config I described.
From what I gather, you seem sure your Pi is blocking traffic… Have your tried service firewall stop (or disable)? Just during testing at least?
Yeah, I know a bridge it’s an L2 device, but there’s thing called a transparent firewall (a bridge that filters traffic,) and OpenWRT is quite capable of that (and then some) so y’know, cover all bases.
Sidenote,
(Very long sidenote)
I recently switched ISPs; from fiber to fiber, from PPPoE to IPoE[1]. I did it bc the new one has static addresses which ended up being the top cause (well, second, the top is sheer unbridled staff incompetence) of the many problems I’ve had since, among these is that any second device DHCP client that gets on the ONTs[2] access VLAN would get the next available IP address from the one that’s statically assigned to me (yet I’m still using ******* DHCP), if I’m doing stuff, it’s then the firewall who might get bumped up, thus losing its address until its released.
During this time I’m not using my own address but one close to it, I can ping public hosts, I even have DNS resolution, but I don’t have full Internet access.
And the thing about IPoE, though basically the same thing as DHCP, it’s not just assignment of the address like DHCP would be, the DHCPREQUESTsubmessages, so to speak, are what triggers authorization into the network it’s a whole thing but it means that you can’t just assign your own static address manually.
What?! Me!? No, I’m not getting angry. You are getting angry.
By the numbers I’ll assume you have a dynamic address; the other thing I learned when I canceled my static address briefly (so I could get faster service) is that carriers do CGN if you don’t pay extra for an autonomous address, and even then they’re so petty that they cycle your public address daily regardless if there was any need (such as a release, reboot, etc), perhaps, if they are keeping track of it and of MAC addresses, they might be applying artificial locks.
Hmm…
Good luck!
Those extra 8 bytes though… Huge difference (config-wise.) ↩︎
I have two: the backdoored one (Huawei, ISP’s) and the compromised one (TP-Link, Amazon’s), they’re bridges, so whatever. ↩︎
@Ray3 - while @senseivita has an interesting point about the firewall, there is presumably nothing currently in the firewall that would do any bridge filtering.
The fact that your bridge is not operating properly -- even if it is firewall related (I'm a bit skeptical of this theory, anyway) -- is not expected. It's really hard to know what you've done with your config during this experiment, but it's clear that there is something that doesn't make any sense.
I cannot stress how strongly I suggest that you follow my earlier advice to start with a completely default config (+drivers) and then add your second Ethernet port to the bridge and make sure it works in the context of OpenWrt's lan + DHCP server. This simple test will prove (or disprove) the proper functioning of the bridge in a near-default state.
I’m going to start from scratch in a couple days , just busy rn will let you know how it goes . Only thing I done with current setup was Disable firewall , DNS , DHCP6 and IPV6
Add eth 1 and 0 to the bridge and set Protocol to unmanaged . Download drivers etc for Eth1
Nothing else was done in terms of adjusting any other settings