Replies: 6 comments 1 reply
|
You goal is fine and doable. There is a major big issue in your configs on your switch configuration. The main point is that eth0-eth3 are not distinct adapters but they are DSA mappings to RJ45 switch ports. Not sure if the official Openwrt DSA drivers (not available in tch firmwares) behave differently, but here with your current config the host connected to RJ45 LAN port mapped to eth3 is able to send packets to every other host connected on other switch ports since they all belong to the same VLAN. All you said so far in configs is that packets arriving at the switch from that RJ45 port and exiting the switch from the CPU port and showing up into eth3 device will be considered as being related to lan2 interface. You need to enable VLAN on the switch and set the first three ports as part of a different VLAN then the fourth. AFAIR you must set the switch to tag packets going to the CPU even if DSA is used. But that never had much sense to me (maybe DSA driver limitation/bug by bcm? ). |
|
So does that mean I need to do something like the answer in this post: |
|
I have tried the config below, and it is worse than before: the DHCPDISCOVER doesn't reach dnsmasq at all. At least the other way it was just the return DHCPOFFER that was lost. EDIT: I have added a new switch stanza as follows: and changed the device options in the switch_vlan stanzas to match, and the DHCPDISCOVER messages now arrive and the DHCPOFFER gets sent, but it still doesn't arrive back at the requesting client. The VLAN configuration has made no difference at all. |
|
Edit: below seems to only apply for DJA0231 firmware 18.3.c. See next post if using firmware 20.3.c. Just coming back around to this rather old post, but I've managed to get eth3 working on its own dedicated VLAN using a similar Technicolor DJA0231 modem/router. This may also work on the DJA0230 that @seud0nym looked like he was trying to use, but I don't have a unit here to try it on. Beforehand I was having similar issues with the eth3 refusing to hand out a DHCP lease to a connected device on VLAN 103. eth0 - eth2 on VLAN were working OK.
Long story short, the following configs get things working on my DJA0231. As per the original requirements of @seud0nym, eth0 - eth2 remain operational as normal LAN access ports at 192.168.145.1 and eth3 is segregated from the others as 192.168.103.1. Both networks freely hand out DHCP leases correctly. /etc/config/network:/etc/config/dhcp:/etc/config/firewall:Although, there's obviously nothing stopping you creating your own firewall rules in the router to limit how network traffic on |
|
Update: the above mods to the The good news is is that it still seems possible to do it on the newer 20.3.c.xxxx firmware. The better news is is that it seems to be completely doable from within the web GUI interface rather than through command line manipulation of the UCI configs. When I was originally experimenting with this on the older 18.3.c firmware, the GUI didn't generate a working config for me, which is how I ended up down the command line rabbit hole. The more recent firmware seems to have fixed this.
That should be it. Ethernet ports 1-3 will now be accessible on the regular LAN subnet and port 4 will be isolated from the others on VLAN 103 as 'lan2'. The GUI even auto-creates a new set of firewall rules to cover the lan2 network with similar policies as the Guest networks, so you don't need to fiddle with them unless you're after something specific. |
Yes, that is correct. Although the information may be relevant/adaptable to other users who might be attempting to do something similar using uci on their (non-Telstra) Technicolor units.
Indeed, I was initially going to raise it as an issue over at your repo, but it looked like creation of new issues was locked out; I was unable to kick one off. But I agree with you - now I know 20.3.c seems to 'fix' the creation/usage of local VLANs the logical solution would be to disregard 18.3.c and upgrade to a newer version as a first step to putting these units into service. |
Uh oh!
There was an error while loading. Please reload this page.
I am trying to move a single LAN port (in this case eth3) to a different subnet, similar to the way that the Guest Wi-Fi runs on a different subnet.
The problem I am encountering is that there seems to be a routing issue. I can see from the logs that the router receives the DHCPREQUEST and sends the DHCPOFFER, but it never arrives back at the client. I have used iptables TRACE to ensure that it is not being blocked by a firewall rule.
I applied the changes by duplicating what the Guest network does.
Here are my config files:
/etc/config/network:
/etc/config/dhcp
To simplify the firewall settings, I just added the new
lan2interface to the Guest1 firewall zone, as that does what I want:Output of various commands:
I am hoping I have just missed something simple...
Thanks.
All reactions