Rpi4 < $(community_build)

try this...

uci set zerotier.sample_wulfy23.enabled='1'
uci commit zerotier
/etc/init.d/zerotier enable
/etc/init.d/zerotier start

can PM about this too... (other than findings main points... as it will also probably drag on a bit)

1 Like

so @moeller0 does this look relevent

unknown  2 485 src=192.168.1.11 dst=224.0.0.2 packets=4 bytes=128 [UNREPLIED] src=224.0.0.2 dst=192.168.1.11 packets=0 bytes=0 mark=0 use=1

lan has igmp snooping enabled but iptv is separate zone... firewall?

##### uci show firewall | grep -i iptv
firewall.@zone[1].network='wan' 'wan6' 'IPTV' 'accessmodem'

####### uci show network | grep -i iptv
network.IPTV=interface
network.IPTV.device='eth1'
network.IPTV.proto='static'
network.IPTV.ipaddr='10.10.10.1'
network.IPTV.netmask='255.255.255.0'

basically doing some reading now on the whole extra zone / topology thing cause it's new to me as well... but like moeller first stated... mcast seems to run pretty good and could be some sort of 'unicast-command' over the zones thing or something...

(and what role if any a smart switch might have in that)

hmmm...

lead1

https://unix.stackexchange.com/questions/464731/multicast-traffic-is-able-to-poke-a-hole-into-the-netfilter-connection-tracking

googled conntrack 'unknown proto'...

this talks about something called pim?

excerpt:

IGMP packets coming from LAN, to allow the router to keep knowing which multicast clients are listening:

iptables -A INPUT -i br0 -p igmp -j ACCEPT



My specific setup is using pimd and PIMv2, I don't know if this protocol is always used or not, but I had to allow the PIM protocol for it to work while keeping the DROP policy, when the source IP wasn't just 192.0.2.1 (but 10.4.4.5):

iptables -A INPUT -s 192.0.2.1 -i eth0 -p pim -j ACCEPT

???

mrd6 - 2013-11-30-c805eb33255dbc0b6647d463c6c67d1c9d3105a0-3 - Multicast is becoming a major component in next generation networks, used in several scenarios, from video broadcasting to multimedia conferencing.  In order to be implemented, new technology needs supporting hardware and  software across a set of devices and systems. MRD6 is an implementation of  a modular IPv6 Multicast Routing Framework for the Linux operating system  and provides MLDv2 (as well as MLDv1), PIM-SM and MBGP support.
pimbd - 2018-06-19-dbf4e5913b06e3160f506df15e6a047a403a5f21-2 - This package provides a daemon which implements the Protocol Independent Multicast BIDIR routing protocol. Note that a routing protocol must be  installed and running in order for PIM to function.

next stop likely a full tcp-dump of both sides of everything or hopefully just the iptv stuff if I can get my head around how to grab it all (likely everything will be cleaner/safer)...

1 Like

I honestly do not know, I do not use/have IPTV so can neither test not have first hand experience, I just wanted to chime in as I had heard the phenotype, IPTV works after channel switch but fails after a short while before with IGMP issues as root cause.

3 Likes
stable [newer-major] 3.5.317-2(3.5.315-3)

should I upgrade?

maybe... kernel got a few bumps (>5.10.87)

appears very good to me so far...

1 Like
stable [newer-major] 3.5.317-2(3.5.315-3)   flashin progess[s]... [#failed>shasum-chk-issue

tried again and it is again stuck at this

stable [newer-major] 3.5.317-2(3.5.315-3)   flashin progress[p]... []  twicedaily[refresh]  [backup]  [tty]
1 Like

thanks... some sort of issue with actually pulling the image down and not the shasum...

re-uploaded another build... may work (click refresh first)... otherwise can be installed manually and i'll investigate a bit more later when the network is quiet...

thanks alot...

1 Like
Server:		8.8.8.8
Address:	8.8.8.8#53

Non-authoritative answer:
Name:	openwrt.org
Address: 139.59.209.225
Name:	openwrt.org
Address: 2a03:b0c0:3:d0::1af1:1

https-dns-proxy dns proxy not working after update

1 Like

cheers... expected (no time to fix yet... and didn't get debug output from the debug script)

can you run this for me...

grep 'ENABLEDSERVICES' /root/wrt.ini
/etc/init.d/https-dns-proxy enabled; echo $?
logread | grep https
1 Like
 ENABLEDSERVICES="sqm simple-adblock https-dns-proxy nft-qos banip"   #[fboot/upgrade] enable+start
# ENABLEDSERVICES="sqm banip adblock"
 /etc/init.d/https-dns-proxy enabled; echo $?
0
 logread | grep https
[root@network /]#

do you need anything else before I restart these services?

1 Like

is there a space before this variable? (meh looks like that wont be the problem here... but make sure no spaces before enabled variables)

1 Like


here? I think there is space before it.

1 Like

tidied the logic for this... even accidentally added to my ENABLEDSERVICES and upgraded/downgraded to a new rebuild of 21.02.1 and everything worked...

just did not test 'pppoe'/modem reset... but you will get debug messages now... so all you should have to do is;

logread | grep https

if there are more problems...

1 Like
stable uptodate: 3.5.317-5  twicedaily[refresh]  [backup]  [tty]
logread | grep https
Mon Dec 20 11:00:24 2021 user.notice https-debug: i:guest a:ifup MSG: EN[yes] srv[no] ok:1
Mon Dec 20 11:00:24 2021 user.notice https-debug: ifup of guest [NOTAWAN]
Mon Dec 20 11:00:24 2021 user.notice https-debug: i:lan a:ifup MSG: EN[yes] srv[no] ok:1
Mon Dec 20 11:00:24 2021 user.notice https-debug: ifup of lan [NOTAWAN]
Mon Dec 20 11:00:25 2021 user.notice https-debug: i:IPTV a:ifup MSG: EN[yes] srv[no] ok:1
Mon Dec 20 11:00:25 2021 user.notice https-debug: ifup of IPTV [NOTAWAN]
Mon Dec 20 11:00:25 2021 user.notice https-debug: i:accessmodem a:ifup MSG: EN[yes] srv[no] ok:1
Mon Dec 20 11:00:25 2021 user.notice https-debug: ifup of accessmodem [NOTAWAN]
Mon Dec 20 11:00:26 2021 user.notice https-debug: i:loopback a:ifup MSG: EN[yes] srv[no] ok:1
Mon Dec 20 11:00:26 2021 user.notice https-debug: ifup of loopback [NOTAWAN]
Mon Dec 20 11:00:35 2021 user.notice https-debug: i:wan a:ifup MSG: EN[yes] srv[no] ok:1
Mon Dec 20 11:00:35 2021 user.notice https-dns-proxy: Reloading https-dns-proxy due to ifup of wan
Mon Dec 20 11:00:35 2021 user.notice https-dns-proxy: Starting service ✓
Mon Dec 20 11:00:36 2021 user.warn kernel: [   48.302891] 15-services> Stopping and disabling https-dns-proxy [notenabled]
Mon Dec 20 11:00:40 2021 user.warn kernel: [   52.853054] 15-services> > ENABLEDSERVICES: sqm simple-adblock https-dns-proxy nft-qos banip [/root/wrt.ini] [enable+start]
Mon Dec 20 11:00:41 2021 user.warn kernel: [   52.990246] 15-services> Starting and enabling https-dns-proxy
Mon Dec 20 11:00:45 2021 user.warn kernel: [   56.984281] 45311-luci-themes> Argon theme v2.2.3-5[default] courtesy of: https://github.com/jerrykuku/luci-theme-argon
Mon Dec 20 11:00:54 2021 user.notice https-debug: i:IPTV a:ifdown MSG: EN[yes] srv[yes] ok:1
Mon Dec 20 11:00:54 2021 user.notice https-debug: i:accessmodem a:ifdown MSG: EN[yes] srv[yes] ok:1
Mon Dec 20 11:00:55 2021 user.notice https-debug: i:guest a:ifdown MSG: EN[yes] srv[yes] ok:1
Mon Dec 20 11:00:55 2021 user.notice https-debug: i:lan a:ifdown MSG: EN[yes] srv[yes] ok:1
Mon Dec 20 11:00:57 2021 user.notice https-debug: i:guest a:ifup MSG: EN[yes] srv[yes] ok:1
Mon Dec 20 11:00:57 2021 user.notice https-debug: ifup of guest [NOTAWAN]
Mon Dec 20 11:00:57 2021 user.notice https-debug: i:lan a:ifup MSG: EN[yes] srv[yes] ok:1
Mon Dec 20 11:00:57 2021 user.notice https-debug: ifup of lan [NOTAWAN]
Mon Dec 20 11:00:58 2021 user.notice https-debug: i:IPTV a:ifup MSG: EN[yes] srv[yes] ok:1
Mon Dec 20 11:00:58 2021 user.notice https-debug: ifup of IPTV [NOTAWAN]
Mon Dec 20 11:00:58 2021 user.notice https-debug: i:accessmodem a:ifup MSG: EN[yes] srv[yes] ok:1
Mon Dec 20 11:00:58 2021 user.notice https-debug: ifup of accessmodem [NOTAWAN]
Mon Dec 20 11:00:59 2021 user.notice https-debug: i:loopback a:ifup MSG: EN[yes] srv[yes] ok:1
Mon Dec 20 11:00:59 2021 user.notice https-debug: ifup of loopback [NOTAWAN]
Mon Dec 20 11:01:08 2021 user.notice https-debug: i:wan a:ifup MSG: EN[yes] srv[yes] ok:1
Mon Dec 20 11:01:08 2021 user.notice https-dns-proxy: Reloading https-dns-proxy due to ifup of wan
Mon Dec 20 11:01:08 2021 user.notice https-dns-proxy: Starting service ✓
Mon Dec 20 11:01:30 2021 user.notice https-dns-proxy: Starting service ✓

But it is still showing inside pi4

Server:		8.8.8.8
Address:	8.8.8.8#53

Non-authoritative answer:
Name:	openwrt.org
Address: 139.59.209.225
Name:	openwrt.org
Address: 2a03:b0c0:3:d0::1af1:1

restarting the dnsmasq and https-dns-proxy fixed it.

Server:		127.0.0.1
Address:	127.0.0.1#53

Non-authoritative answer:
Name:	openwrt.org
Address: 139.59.209.225
Name:	openwrt.org
Address: 2a03:b0c0:3:d0::1af1:1
1 Like

very useful... you're a patient and persistent dude neil1

additional debug output will be in next image (tba)... like I said I upgraded with this service twice and no probs... we are kinda back to where we were ages ago with this...

apart from the hassle for you... it's an interesting learning experience, hopefully we nail it on the next upgrade... :crossed_fingers:

1 Like

HI,
I was trying to boot from a 32GB USB drive(team c211). I wrote the factory image using Rufus and the RPI booted. but if I reboot the pi from Luci the pi doesn't boot anymore. the red and green LEDs lights up and it stays like that.
what am I doing wrong? or is USB booting not working properly?

Appreciate your work.

by any chance did you restore any config prior to reboot?
no mmc card was ever inserted during all this process?

if-no-to-both-the-above

if you are able to plug the usbstick into a pc... then;

  1. fsck both partitions first... then;

mount the first partition

cat /mountpointofpartition1/cmdline.txt
fdisk -l /dev/drive
  1. state usb drive type is also probably relevant whoops... you did that already
    ok... so looks like a '3.2 / newish one' neither here nor there but worth noting...

also if I can get your BOOT_ORDER in firmware would be good... (but not strickly needed yet,,, if it booted once... then should be ok i think)
edit: or maybe it is solid green is something about not being able to read a disk (sdonly?) early... could be fsck here...

on the rpi itself

vcgencmd bootloader_config | grep "^BOOT_ORDER"
vcgencmd bootloader_version | head -n1

(same would go for trying another usb drive... if it booted once, doubt this is relavent)


hmmmm... reboot from luci... need to think about that... to be honest i've not tested usb operation in quite a while (and since ROOTFSEXPAND was implemented) so could be a new bug (however that will only happen during upgrade so maybe not that)...

Right now I'm running it from an sd card and I got this

root@RPi4B /36# vcgencmd bootloader_config | grep "^BOOT_ORDER"
BOOT_ORDER=0xf14
root@RPi4B /38# vcgencmd bootloader_version | head -n1
2021/12/02 11:08:03
1 Like

great.. checks out perfect (that means wont matter if sdcard was ever inserted or not)... and config restore question?

I didn't restore a config. I changed LAN IP and connected to the internet through PPPoE and rebooted, then it happened. also if I flash it on the USB drive it says update unavailable on Luci but if I use the sd card it says up to date.
I don't have a Linux system to run fsck. is this doable on windows cmd?

1 Like