Rpi4 < $(community_build)

anon50098793 · September 29, 2021, 7:40am

Yup... perfect!

OpenWrt is based on traditionally small amounts of flash memory ( 8M to 128M )... where only tiny backup files are/can-be stored...

In this build... i've made several 'enhancements' to support

larger amounts of packages
expansion of the rootfs
but the underlying backup method is still traditional ( although with a stock image /boot is maybe 50M not 300M )

I tried to make it very clear when I implemented ROOTFSEXPAND that this will be an underlying limitation... ( and have told anyone using large datasets to use an exteral drive / mount for those ) since day 1... but it is good for you to test the limits, and see how errors manifest first hand... (and edge cases with verbose debugging help I learn alot from... so thanks)

( i.e. I still need to make this advice more clearer... and perhaps in the future I will make some more modifications to better support large data migration )

these constraints (and solutions) will exist on official (all) images...

ToasterDEV · September 29, 2021, 7:55am

Thank YOU wulfy, honestly you're the most patient developer I've dealt with so far, and as you say this experience has definitely teached me a lot of somethings, having you along for the ride certainly has helped my sanity from dwindling any lower

Then again, to tell you the truth the search function only helped me so much in finding out that you had already answered this sort of question, as I just found out about the quote above from checking the replies to the OP, so maybe something like a README.md on the download site or a warning to check the replies on the OP would help discoverability if you're still able to edit that one (I honestly thought the replies were either praise from fellow users or reserved posts for thread managing).

In any case, I sure am glad that I can put to rest this latest adventure, and a donation is surely coming your way after payday .

Thanks for everything, I guess i have my work cut out tomorrow.

anon50098793 · September 29, 2021, 7:57am

one it's setup it works beautifully... (and upgrades are fast as large data does not need to be moved)

[root@dca632 /usbstick 53°] mount | grep usbstick
/dev/sda1 on /usbstick type ext4 (rw,relatime)

[root@dca632 /usbstick 52°] uci show fstab | grep -A3 usbstick
fstab.@mount[2].target='/usbstick'
fstab.@mount[2].uuid='aa8fca3f-7077-4f41-a289-ca04fc22470d'
fstab.@mount[2].enabled='1'
fstab.@mount[2].enabled_fsck='1'

[root@dca632 /usbstick 52°] df -h | grep usbstick
Filesystem                Size      Used Available Use% Mounted on
/dev/sda1               112.3G     29.8G     76.8G  28% /usbstick

ToasterDEV · September 29, 2021, 8:02am

It looks beautiful indeed! Now I just need to harvest the convention bag for a stick 'till I can get my hands on another NVMe drive. Not too shabby for being my first homelab!

neil1 · September 30, 2021, 5:44am

/usr/lib/lua/luci/dispatcher.lua:427: /etc/config/luci seems to be corrupt, unable to find section 'main'

should I reboot?

anon50098793 · September 30, 2021, 5:48am

hmmm... that's the second time you've had an odd /etc/config/luci error but seems uniq to you...

so will be really hard for me to troubleshoot... I think last time we were thinking about failing sdcard or something... (what model is the sdcard?)

if nobody else has the issue... likely that or related to some additional package/manual change? but also suspect the error is a little misleading... like that config file is not the real issue or something... is there any relationship between high-io (lots of file copy operations) and the error?

you only need the last rpcd restart command see below


ucivalidate.sh 2>/dev/null | grep luci
cat /etc/config/luci
###################################
curl -sSL https://raw.githubusercontent.com/wulfy23/rpi4/master/utilities/config-luci > /etc/config/luci
rm -rf /tmp/luci*
/etc/init.d/uhttpd restart; /etc/init.d/rpcd restart

40 results on the forum...

'rebooting fixes but comes back'

'make sure rpcd is running'

ok this seems closest...
'And I seem to be able to reproduce the crash, even after your suggested move. Whenever I browse to the connection stats page and then somewhere else, I get an error'

so... some sort of rpcd crash related to visiting the 'connections' page?

think you should join in on the thread above ( or this github issue ) as it's looking like a non-build related resource problem (conntrack js overheads/quirks spamming rpcd? lib-json-c struct overflow? beyond my paygrade!)...

lol@slim-wrt workaround! just remove connections!

maybe see if this helps... (needs restart and browser cache clear);


sed -i 's|pollInterval=3|pollInterval=10|g' /www/luci-static/resources/view/status/connections.js

neil1 · September 30, 2021, 11:28pm

It is fine now after reboot.
Yes, I was trying to check status > realtime graphs > connections

memory card is from Kingston select plus 32GB

anon50098793 · October 1, 2021, 3:06am

fyi...;

updated the top post with link to this discussion and large bold lettering...
and a link to a newly created (but can be better) github guide...
https://github.com/wulfy23/rpi4/blob/master/misc/guides/i_have_large_data.md
also modified sysupgrade to inform the next person who get's this... so instead of;

Failed to create the configuration backup

they will get;

############################################
Failed to create the configuration backup
############################################
it's probably too big (max 200MB)
remove large directories from your /etc/sysupgrade.conf
and backup / restore them manually
############################################

thanks again for the feedback...
(note: 200MB is the tar.gz limit which is probably something closer to 550MB in raw data files depending on the filetype)

ToasterDEV · October 1, 2021, 6:01am

Every time we talk you impress me more and more, honestly it's perfect!

Thanks for all the help so far!

And while on the topic of ~~Big~~ large data, I caught a glimpse that you were able to get ffmpeg to use hardware acceleration to a degree and was wondering if you had kept the libraries around so as to use them with Jellyfin per this guide, since I'm able to see the onboard encoder just fine.

Also, not sure if this is something that "requires" fixing, but it seems that the original youtube-dl is being superceded by this fork (yt-dlp), since the mantainers of the original project don't seem to be as active as in previous years, so while I don't use the feature personally, it might be worth it to take a look into changing over to the newer binary and giving it a test drive.

Also seem to be having some issues with both Wireguard and Transmission not opening their ports even after explicitly opening them in the firewall, but I'm pretty sure that has more to do with the packages rather than the build.

The upgrade worked correctly from yesterday's convo over to today's current build, and aside from some connection timeouts I'm looking into, everything's peachy so far.

Will keep you posted if I find anything else, and thanks again for all your guidance!

anon50098793 · October 1, 2021, 6:11am

cheers... will keep an eye on that...

ffmpeg is 'ripped-off' from alpine linux... ( extracted files manually and it gets downloaded on firstboot due to size... ) ... there are one or two more ( rclone, pastebinit etc. etc.)

i'll have to readup a little on this to get my bearings... but for packages not in openwrt I typically see if I can rip them out of alpine (or sometimes debian) as above...

findings-or-opinion

had a quick look over the jellyfin docs and in all honesty for this type of stuff (complex rpi4 video) you'll be better off(need) to be running the full blown distro(kernel) as the host os...

will save you a bunch of time and hassle... so if I were you, i'd look into purchasing an additional rpi4 (or just using x64) for this type of thing...

also has the huge benefit of not needing to update/zap the whole thing when you update the router...

a fun recent attempt...

[ /usbstick 49°]# kodi

[ /usbstick 47°]# ps w | grep kodi                                                                     
19191 root      0:00 {kodi} /bin/sh /usr/bin/kodi                                                                  
19199 root      0:00 /usr/lib/kodi/kodi-x11                                                                        
19205 root      0:00 grep kodi

ERROR: Unable to create GUI. Exiting

thanks for the report... first i've heard relating to this build but i've seen quite a few master related threads around the forum...

if it's urgent/persists i can probably try to implement a workaround (or maybe use r17530 or try r17637)... but as you say probably more to do with packages/netifd...

ToasterDEV · October 1, 2021, 6:32am

Well that's an interesting tidbit, all this time I've been downloading rclone manually! Will keep an eye on that for the next build then.

Long story short it seems that the OpenMAX libraries are not shipped within the Docker container, and HW acceleration only works on the linuxserver.io image as long as both the library path and the device are shared to the container, but otherwise it seems like a fairly standard implementation. The only part that gives me pause is that the container's README mentions the other video devices that the RPi exposes while on Raspbian (video10, video11, video12, etc.), so there's a chance the way VideoCore exposes the hardware would require creating the rest of the device instances (then again, this is only speculation). On the other hand, it seems the Reddit post was used as the basis for the official snippet on their documentation according to this comment, so the paper trail checks out in regards to the requirements.

It's probably something related to the master branch, I've had this issue since r17443 at least with Wireguard (even though the port is open and the service running not even nmap is able to make tcpdump catch a packet), but if there's anything I could provide to help diagnose the issue I'd be glad to help.

Fortunately nothing's urgent atm, but if you have something in mind I'm game.

anon50098793 · October 1, 2021, 6:33am

for now... at least on 'current'(r1763x+) you can use rclone-aarch64 to install it... but it sort of needs an initscript too... for now thats up to the user...

or just

cd /
wget https://github.com/wulfy23/rpi4/raw/master/utilities/rclone.tar.gz
tar -xvzf rclone.tar.gz

this is more for your own purposes... way too much output to post... but you can try...

cp /sbin/hotplug-call /sbin/hotplug-call.orig
cp /sbin/hotplug-call-debug /sbin/hotplug-call

to see some verbose hotplug related info... ( cat /tmp/hotplug...)...

but i'll poke around and digest the other posts and your feedback for a bit because I think hotplug is a bit late in the chain ( for a root case but can be useful to catch exceptions for a workaround )

ToasterDEV · October 1, 2021, 7:00am

Fair enough , I'm still getting used to uci, so I think I'll stick to the second option.

Okay, I'm interested and scared at the same time, but it's certainly worth a try!

So perhaps the issue is more of a layer 2 thing I presume, I'll keep you posted if anything weird comes up with hotplug. For the moment I'll just say that my rtl8152-based adapter dropped the error rates considerably after removing the kernel module (kmod-usb-net-rtl8152), it seems that on the "current" branch the rtl8150 non USB driver is currently more reliable, but I haven't been able to reproduce after today's upgrade the same error messages I was getting about restarting the interface using xHCI, so maybe that was more of a coincidence or a fluke.

Again, thanks for all the help!

anon50098793 · October 2, 2021, 3:34am

if you get a chance and you are still on the same build... can you PM me the output from

ubus -S call network.interface dump

when the interfaces / network has not come up correctly?

anon50098793 · October 3, 2021, 3:53pm

i've put an experimental mtr(4) in the luci diagnostics page... but XHR is limited to 30secs so you will likely get a timeout error if you try to test this for now... at least for the first run I get it...

second run

sammutd88 · October 3, 2021, 8:31pm

Wireguard status page now working on new build. Well done.

anon50098793 · October 4, 2021, 1:57pm

lol... you tested and reported it... i just passed that on and the upstream guys fixed it... so thankyou...

speaking of which...

nmap is broken on r17674...
anyone on r17530 there is no rush to upgrade even tho' I just called r17674 'stable'

thanks to @vgaetera anyone using rpi4.qos can now graphically add/edit some ipsets for custom domains / priority also... (network > dhcp and dns > [ip sets])

dns_dhcp_ipsets

neil1 · October 5, 2021, 12:18pm

stable uptodate: 3.5.75-6

upgraded without any issue.

quky · October 6, 2021, 2:36pm

need help can not get to open port 443 to work
got a raspberry pi 4 running the latest firmware and every thing is working like it is supposed to , but can not get port 443 open

tcpdump por 443 not working

port 443
root@rpi4-router /37#  tcpdump -v -n -i eth1 port 443 and src canyouseeme.org
tcpdump: listening on eth1, link-type EN10MB (Ethernet), capture size 262144 bytes
09:23:56.603033 IP (tos 0x20, ttl 46, id 0, offset 0, flags [DF], proto TCP (6), length 52)
    52.202.215.126.443 > 73.232.38.41.49601: Flags [S.], cksum 0xedc4 (correct), seq 3757102762, ack 1513867147, win 26883, options [mss 1460,nop,nop,sackOK,nop,wscale 7], length 0
09:23:56.603462 IP (tos 0x20, ttl 46, id 0, offset 0, flags [DF], proto TCP (6), length 52)
    52.202.215.126.443 > 73.232.38.41.57980: Flags [S.], cksum 0xf0d3 (correct), seq 2196234883, ack 3227553484, win 26883, options [mss 1460,nop,nop,sackOK,nop,wscale 7], length 0
09:23:56.649319 IP (tos 0x20, ttl 46, id 59772, offset 0, flags [DF], proto TCP (6), length 40)
    52.202.215.126.443 > 73.232.38.41.49601: Flags [.], cksum 0x94ba (correct), ack 518, win 219, length 0
09:23:56.649557 IP (tos 0x20, ttl 46, id 56659, offset 0, flags [DF], proto TCP (6), length 40)
    52.202.215.126.443 > 73.232.38.41.57980: Flags [.], cksum 0x97c9 (correct), ack 518, win 219, length 0
09:23:56.650242 IP (tos 0x20, ttl 46, id 59773, offset 0, flags [DF], proto TCP (6), length 1500)
    52.202.215.126.443 > 73.232.38.41.49601: Flags [.], cksum 0xb31f (correct), seq 1:1461, ack 518, win 219, length 1460
09:23:56.650669 IP (tos 0x20, ttl 46, id 59774, offset 0, flags [DF], proto TCP (6), length 1500)
    52.202.215.126.443 > 73.232.38.41.49601: Flags [.], cksum 0x20c4 (correct), seq 1461:2921, ack 518, win 219, length 1460
09:23:56.650670 IP (tos 0x20, ttl 46, id 59775, offset 0, flags [DF], proto TCP (6), length 1216)
    52.202.215.126.443 > 73.232.38.41.49601: Flags [P.], cksum 0x98f5 (correct), seq 2921:4097, ack 518, win 219, length 1176
09:23:56.651118 IP (tos 0x20, ttl 46, id 56660, offset 0, flags [DF], proto TCP (6), length 1500)
    52.202.215.126.443 > 73.232.38.41.57980: Flags [.], cksum 0x9faf (correct), seq 1:1461, ack 518, win 219, length 1460
09:23:56.651119 IP (tos 0x20, ttl 46, id 56661, offset 0, flags [DF], proto TCP (6), length 1500)
    52.202.215.126.443 > 73.232.38.41.57980: Flags [.], cksum 0x23d3 (correct), seq 1461:2921, ack 518, win 219, length 1460
09:23:56.651120 IP (tos 0x20, ttl 46, id 56662, offset 0, flags [DF], proto TCP (6), length 1216)
    52.202.215.126.443 > 73.232.38.41.57980: Flags [P.], cksum 0x9c04 (correct), seq 2921:4097, ack 518, win 219, length 1176
09:23:56.651759 IP (tos 0x20, ttl 46, id 56663, offset 0, flags [DF], proto TCP (6), length 438)
    52.202.215.126.443 > 73.232.38.41.57980: Flags [P.], cksum 0xb517 (correct), seq 4097:4495, ack 518, win 219, length 398
09:23:56.651759 IP (tos 0x20, ttl 46, id 59776, offset 0, flags [DF], proto TCP (6), length 438)
    52.202.215.126.443 > 73.232.38.41.49601: Flags [P.], cksum 0x1f75 (correct), seq 4097:4495, ack 518, win 219, length 398
09:23:56.694506 IP (tos 0x20, ttl 46, id 59777, offset 0, flags [DF], proto TCP (6), length 314)
    52.202.215.126.443 > 73.232.38.41.49601: Flags [P.], cksum 0xf4f1 (correct), seq 4495:4769, ack 644, win 219, length 274
09:23:56.694507 IP (tos 0x20, ttl 46, id 56664, offset 0, flags [DF], proto TCP (6), length 314)
    52.202.215.126.443 > 73.232.38.41.57980: Flags [P.], cksum 0xbd3c (correct), seq 4495:4769, ack 644, win 219, length 274
09:23:56.746637 IP (tos 0x20, ttl 47, id 49684, offset 0, flags [DF], proto TCP (6), length 60)
    52.202.215.126.46241 > 73.232.38.41.443: Flags [S], cksum 0x56bb (correct), seq 765394427, win 26883, options [mss 1460,sackOK,TS val 3925950447 ecr 0,nop,wscale 7], length 0
09:23:56.783646 IP (tos 0x20, ttl 46, id 56665, offset 0, flags [DF], proto TCP (6), length 40)
    52.202.215.126.443 > 73.232.38.41.57980: Flags [.], cksum 0x8113 (correct), ack 1550, win 233, length 0
09:23:57.744387 IP (tos 0x20, ttl 47, id 49685, offset 0, flags [DF], proto TCP (6), length 60)
    52.202.215.126.46241 > 73.232.38.41.443: Flags [S], cksum 0x55c1 (correct), seq 765394427, win 26883, options [mss 1460,sackOK,TS val 3925950697 ecr 0,nop,wscale 7], length 0
09:23:59.747779 IP (tos 0x20, ttl 47, id 49686, offset 0, flags [DF], proto TCP (6), length 60)
    52.202.215.126.46241 > 73.232.38.41.443: Flags [S], cksum 0x53cc (correct), seq 765394427, win 26883, options [mss 1460,sackOK,TS val 3925951198 ecr 0,nop,wscale 7], length 0
09:23:59.904045 IP (tos 0x20, ttl 46, id 56666, offset 0, flags [DF], proto TCP (6), length 1500)
    52.202.215.126.443 > 73.232.38.41.57980: Flags [.], cksum 0xbc20 (correct), seq 4769:6229, ack 1550, win 233, length 1460
09:23:59.904368 IP (tos 0x20, ttl 46, id 56667, offset 0, flags [DF], proto TCP (6), length 1500)
    52.202.215.126.443 > 73.232.38.41.57980: Flags [.], cksum 0x2e77 (correct), seq 6229:7689, ack 1550, win 233, length 1460
09:23:59.904596 IP (tos 0x20, ttl 46, id 56668, offset 0, flags [DF], proto TCP (6), length 1176)
    52.202.215.126.443 > 73.232.38.41.57980: Flags [P.], cksum 0x840a (correct), seq 7689:8825, ack 1550, win 233, length 1136

tcpdump port 80 it is working

port 80
root@rpi4-router /37# tcpdump -v -n -i eth1 port 80 and src canyouseeme.org
tcpdump: listening on eth1, link-type EN10MB (Ethernet), capture size 262144 bytes
09:24:58.139300 IP (tos 0x20, ttl 47, id 62609, offset 0, flags [DF], proto TCP (6), length 60)
    52.202.215.126.53449 > 73.232.38.41.80: Flags [S], cksum 0xe639 (correct), seq 3052638069, win 26883, options [mss 1460,sackOK,TS val 3925965796 ecr 0,nop,wscale 7], length 0
09:24:58.179983 IP (tos 0x20, ttl 47, id 62610, offset 0, flags [DF], proto TCP (6), length 52)
    52.202.215.126.53449 > 73.232.38.41.80: Flags [.], cksum 0x664e (correct), ack 1650098655, win 211, options [nop,nop,TS val 3925965806 ecr 2049095793], length 0
09:24:58.180420 IP (tos 0x20, ttl 47, id 62611, offset 0, flags [DF], proto TCP (6), length 52)
    52.202.215.126.53449 > 73.232.38.41.80: Flags [F.], cksum 0x664d (correct), seq 0, ack 1, win 211, options [nop,nop,TS val 3925965806 ecr 2049095793], length 0
09:24:58.221335 IP (tos 0x20, ttl 47, id 62612, offset 0, flags [DF], proto TCP (6), length 52)
    52.202.215.126.53449 > 73.232.38.41.80: Flags [.], cksum 0x6619 (correct), ack 2, win 211, options [nop,nop,TS val 3925965816 ecr 2049095834], length 0

firewall config

config defaults
        option syn_flood '1'
        option input 'ACCEPT'
        option output 'ACCEPT'
        option forward 'REJECT'

config zone
        option name 'lan'
        list network 'lan'
        option input 'ACCEPT'
        option output 'ACCEPT'
        option forward 'ACCEPT'

config zone
        option name 'wan'
        list network 'wan'
        list network 'wan6'
        option input 'REJECT'
        option output 'ACCEPT'
        option forward 'REJECT'
        option masq '1'
        option mtu_fix '1'

config forwarding
        option src 'lan'
        option dest 'wan'

config rule
        option name 'Allow-DHCP-Renew'
        option src 'wan'
        option proto 'udp'
        option dest_port '68'
        option target 'ACCEPT'
        option family 'ipv4'

config rule
        option name 'Allow-Ping'
        option src 'wan'
        option proto 'icmp'
        option icmp_type 'echo-request'
        option family 'ipv4'
        option target 'ACCEPT'

config rule
        option name 'Allow-IGMP'
        option src 'wan'
        option proto 'igmp'
        option family 'ipv4'
        option target 'ACCEPT'

config rule
        option name 'Allow-DHCPv6'
        option src 'wan'
        option proto 'udp'
        option src_ip 'fc00::/6'
        option dest_ip 'fc00::/6'
        option dest_port '546'
        option family 'ipv6'
        option target 'ACCEPT'

config rule
        option name 'Allow-MLD'
        option src 'wan'
        option proto 'icmp'
        option src_ip 'fe80::/10'
        list icmp_type '130/0'
        list icmp_type '131/0'
        list icmp_type '132/0'
        list icmp_type '143/0'
        option family 'ipv6'
        option target 'ACCEPT'

config rule
        option name 'Allow-ICMPv6-Input'
        option src 'wan'
        option proto 'icmp'
        list icmp_type 'echo-request'
        list icmp_type 'echo-reply'
        list icmp_type 'destination-unreachable'
        list icmp_type 'packet-too-big'
        list icmp_type 'time-exceeded'
        list icmp_type 'bad-header'
        list icmp_type 'unknown-header-type'
        list icmp_type 'router-solicitation'
        list icmp_type 'neighbour-solicitation'
        list icmp_type 'router-advertisement'
        list icmp_type 'neighbour-advertisement'
        option limit '1000/sec'
        option family 'ipv6'
        option target 'ACCEPT'

config rule
        option name 'Allow-ICMPv6-Forward'
        option src 'wan'
        option dest '*'
        option proto 'icmp'
        list icmp_type 'echo-request'
        list icmp_type 'echo-reply'
        list icmp_type 'destination-unreachable'
        list icmp_type 'packet-too-big'
        list icmp_type 'time-exceeded'
        list icmp_type 'bad-header'
        list icmp_type 'unknown-header-type'
        option limit '1000/sec'
        option family 'ipv6'
        option target 'ACCEPT'

config rule
        option name 'Allow-IPSec-ESP'
        option src 'wan'
        option dest 'lan'
        option proto 'esp'
        option target 'ACCEPT'

config rule
        option name 'Allow-ISAKMP'
        option src 'wan'
        option dest 'lan'
        option dest_port '500'
        option proto 'udp'
        option target 'ACCEPT'

config rule
        option name 'Support-UDP-Traceroute'
        option src 'wan'
        option dest_port '33434:33689'
        option proto 'udp'
        option family 'ipv4'
        option target 'REJECT'
        option enabled 'false'

config include
        option path '/etc/firewall.user'
        option reload '1'

config redirect
        option target 'DNAT'
        option name 'QukyNASPort5000'
        option src 'wan'
        option src_dport '5000'
        option dest 'lan'
        option dest_ip '192.168.1.180'
        option dest_port '5000'
        list proto 'tcp'
        list proto 'udp'

config redirect
        option target 'DNAT'
        option name 'QukyNASPort50001'
        option src 'wan'
        option src_dport '5001'
        option dest 'lan'
        option dest_ip '192.168.1.180'
        option dest_port '5001'
        list proto 'tcp'
        list proto 'udp'

config redirect
        option target 'DNAT'
        option name 'OctodashPort80'
        list proto 'tcp'
        option src 'wan'
        option src_dport '55001'
        option dest 'lan'
        option dest_ip '192.168.1.114'
        option dest_port '5002'

config redirect
        option target 'DNAT'
        option name 'OctodashPort443'
        option src 'wan'
        option src_dport '443'
        option dest 'lan'
        option dest_ip '192.168.1.114'
        option dest_port '443'
        list proto 'tcp'
        list proto 'udp'
        option enabled '0'

config redirect
        option target 'DNAT'
        option name 'QukyNASPort443'
        option src 'wan'
        option src_dport '443'
        option dest 'lan'
        option dest_ip '192.168.1.180'
        option dest_port '443'
        list proto 'tcp'
        list proto 'udp'
        option enabled '0'

config redirect
        option target 'DNAT'
        option name 'trasnmission9091'
        list proto 'tcp'
        option src 'wan'
        option src_dport '9091'
        option dest 'lan'
        option dest_ip '192.168.1.180'
        option dest_port '9091'

config redirect
        option target 'DNAT'
        option name 'FTP_PCPort22'
        option src 'wan'
        option src_dport '22'
        option dest 'lan'
        option dest_ip '192.168.1.170'
        option dest_port '22'
        list proto 'tcp'
        list proto 'udp'

config include 'timecontrol'
        option type 'script'
        option path '/var/etc/timecontrol.include'
        option reload '1'

config redirect
        option target 'DNAT'
        option name 'webserber80'
        option src 'wan'
        option dest 'lan'
        list proto 'tcp'
        option src_dport '80'
        option dest_port '80'
        option dest_ip '192.168.1.233'

config redirect
        option target 'DNAT'
        option name 'Webserber443'
        option src 'wan'
        option src_dport '443'
        option dest 'lan'
        option dest_ip '192.168.1.233'
        list proto 'tcp'
        option dest_port '443'

any help would be really appreciated

slh · October 6, 2021, 8:36pm

I don't think this issue belongs into this thread (pure software issue, independent of the hardware or this particular community build). You can't redirect port 443, as long as uhttpd (luci) binds to it on all interfaces, as it's currently in use already (by the webinterface).