Rpi4 < $(community_build)

welcome.

you may get some more assistance creating a thread on the general forum...(was build related disabling of wpad) with regards to wireless... anything build related (very little) can be gathered from the command;

opkg list-installed | grep -e hostapd -e wpad; uci show wireless; service | grep wpad

in addition... post a link to your info above

Thank you Wolfy, Here is the output.

hostapd-common - 2020-06-08-5a8b3662-32
hostapd-utils - 2020-06-08-5a8b3662-32
wpad-openssl - 2020-06-08-5a8b3662-32
wireless.radio0=wifi-device
wireless.radio0.type='mac80211'
wireless.radio0.hwmode='11a'
wireless.radio0.path='platform/soc/fe300000.mmcnr/mmc_host/mmc1/mmc1:0001/mmc1:0001:1'
wireless.radio0.htmode='VHT40'
wireless.radio0.disabled='1'
wireless.radio0.channel='52'
wireless.radio0.country='US'
wireless.radio0.cell_density='0'
wireless.default_radio0=wifi-iface
wireless.default_radio0.device='radio0'
wireless.default_radio0.network='lan'
wireless.default_radio0.mode='ap'
wireless.default_radio0.key='somerandomhardtoguesspassword'
wireless.default_radio0.ssid='ap101'
wireless.default_radio0.encryption='psk2+ccmp'
wireless.default_radio0.disabled='1'
/etc/init.d/wpad disabled stopped

1 Like

your wireless is disabled

  • enable and start wpad service
  • go to network > wireless and make sure the network / adapter is enabled
1 Like

Thank you sir. That worked. For some reason WPAD was not enabled by default on install.

1 Like

this has changed through various iterations of the build... ( in the early days I did disable it... now it may depend on what the last install had ) so I cannot really provide a solid answer as to what the expected 'default' is other than to say...

  • all users (using wireless) should check it
  • add it to ENABLEDSERVICES just in case

thanks for highlighting this specific 'quirk' within the build...

EDIT: 21st/April disabled due to lack of input

good to get some testing on this... especially;

  • on links 200Mb/s+ AND/OR
  • people without UE300
  • please disable/stop irqbalance while testing these ( if you have enabled it )
instructions
curl -sSL https://raw.githubusercontent.com/wulfy23/rpi4/master/utilities/20-smp-packet-steering > /etc/hotplug.d/net/20-smp-packet-steering
#and reboot or restart networking
#EDIT: manual curl of this file now requires PACKETSTEERING=1 in /root/wrt.ini
#this can graphically edited at luci > system > startup > local startup
#commenting this out and rebooting (ifup br-lan?) will turn it off
#new builds will have this turned on and it is backported...

after that is fully tested... you can add(update) this and test too...

curl -sSL https://raw.githubusercontent.com/wulfy23/rpi4/master/utilities/rpi-perftweaks.sh > /bin/rpi-perftweaks.sh
#######@/root/wrt.ini
PERFTWEAKS="default" #may be set to "1" already or no entry
#then reboot or just run /bin/rpi-perftweaks.sh
#there is no undo... comment out PERFTWEAKS= then reboot should be close

and if/after you've tested the above... fyi...

PERFTWEAKS=1
POWERPROFILE="quick"
PFAFFINITY="32:f 33:f 26:c"
#PFRENICE=1
#PFSERVICECPU=1 #taskset some procs to cpu's

or whatever will let you re-assign irq-affinity... the other stuff is static for now can be overridden via /etc/perftweaks.txt ... but the commented vars above allow turning on and off... you'd need to reboot to undo tho'

(edit: network restart does not seem to add the usb nics again... so reboot may be needed although the onboard is the most important bit anyway)


also if anyone thinks they may want

  • "packet_steering" as a build default and (edit: now enabled comment out PACKETSTEERING=1 to disable )
  • NOT/NO performance tweaks as default... ( edit: now enabled comment out PERFTWEAKS="default" to disable )

i'd like to hear from you... ( otherwise next upgrade comment out #PERFTWEAKS= because i'll likely backport some defaults in the next build aka insert some vars into your wrt.ini that govern this )

speak now or forever hold your 2c-peice...

troubleshooting

1 Like

I added dnssec in dnsmasq config file

		○ option dnssec '1'
		○ option dnsseccheckunsigned '1'

and i was getting network issues in games. Why is that?

I am now using sg108e with vlan.

2 Likes

does it use other ports?

rpi4.qos classifies;

	UDPCONTROLPT="53,5353,123,67,68,520"
	TCPCONTROLPT="53,5353,22,179,853"

as control traffic... if it's now using something else... then it will likely get placed in a lower teir... ( you didn't exactly explain what you mean by problems... last time we spoke... I said to remove the pc from GAMING_MACS as that variable is not suited to mixed traffic devices... ideally you should add it back and not download on the same machine whilst gaming... (or you can download within a VM also) there are another qos scripts that may suit you better also... )


ok... you'd probably still see some benefit from both... but vlan setup+not super high wan connection means less stuffing around if you just wait for more polished versions...

( but technically it's worth testing under wan@vlan conditions also )... i'll put this on my list...

you will get gains... by just enabling basic(default) steering for now...

uci -q set network.globals.packet_steering='1'; uci commit network; /etc/init.d/network restart

[FIRST-SCRIPT/STEERING]
the main problem is sqm getting cpu-bound over around/above 2-300mbps somewhere... so users with high speeds should see roughly 15-30% gains under peak demands...

[SECOND-SCRIPT]
basically just bumps up the min_freq 600000>900000 the rest is likely superfluous... apart from the INTERRUPT-AFFINITY... which ties into SCRIPT1/STEERING

1 Like

when i try to login it says "connection to server has been interrupted."

I think it some other issue. I removed these two settings from the dnsmasq config and i was able to login.
But now it is again stuck at loading and giving me error "connection to server has been interrupted"
maybe port issue as you mentioned here

yes i removed my pc

1 Like

from the last debug output you sent me... your network ( upload ) showed extremely high contention ( too much load for the speed )... you really need to study more about qos/sqm... and ideally upgrade your wan subscription speed / isp...

read this it explains clearly (using an alternate shaper) how adequate upload bandwidth availability is CRITICAL to everything...

1 Like

for the dnsmasq stuff... you could try adding;

option logqueries '1'

in the main dhcp config... restart dnsmasq... then checking logread when there are errors...

1 Like

looks like it is a issue with background services in windows 10

1 Like

thanks for the update... I should have read the line above a little closer... apologies...

1 Like

Just some SQM questions, it seems like the Rpi4 can handle upload SQM pretty well(comfortable at 800 000kbit/s). But for download it caps at 600 000~kbit/s no matter what settings I use. Is this a restriction of the Rpi4 from a CPU standpoint or should I do some tests for you @wulfy23?

Queue Discipline:
pie
ctinfo_4layercake_rpi4.qos

Link Layer Adaption:
none (default)

I've got Fiber 1G/1G, UE300.

1 Like

no ~931 is the restriction... ( not cpu )

ive never used pie... should be cake for that shaper...

off-topic-note: realized recently that script should really be called;

ctinfo_8layercake_rpi4.qos

due to it instantiating with diffserv8... but i'm happy to just keep the name aligned with where it was pilfered from for provinence reasoning...

i've never really provided much guidance for the SQM-CONFIG setting for use with that script...

verbage

partly because i'm not sure what it can support... but for reference... i've always used it with a bone standard up/down on single wan with practically no other options...

sqm.wan=queue
sqm.wan.interface='eth1'
sqm.wan.download='49470'
sqm.wan.upload='16980'
sqm.wan.linklayer='none'
sqm.wan.enabled='1'
sqm.wan.qdisc='cake'
sqm.wan.script='ctinfo_4layercake_rpi4.qos'
sqm.wan.debug_logging='1'
sqm.wan.verbosity='5'

up to you... but you need to ressign eth0 interrupt affinity (or use packet_steering ) to achieve max throughput...

verbage

i (got off my rear) ran controlled 'internal-fake-GB-wan' testing yesterday ( @dlakelan did so a long time ago ) with and without sqm... so we know where the main impediments are... we just don't know what is 'perfect'-value-s/sane-default/alternate nic behavior... which is something only a user comfortable with messing with IRQ etc. can really assist with... even with my mediocre ( witness-me ) skills its difficult to isolate or interpret tweaking all of these values...

fwiw... i'm now semi-randomly setting...

echo -n c > /proc/irq/32/smp_affinity
echo -n c > /proc/irq/33/smp_affinity
echo -n a > /sys/class/net/eth0/queues/*/*_cpus

and to avoid panic / confusion... most of this is only really relevant for people with WAN OVER ~250-350Mb/s hence why it took me so long to dig into this at all...

this graph is pretty interesting/evident... the spike at the end of monday is the perf testing with defaults which was cpu bound...

you can see high sirq and little to no load on cpu3/4 in the proceeding days...

tuesday onwards are with the current tweaks... sirq barely registers and load is distributed much more evenly across all cores... ( the big spike on tuesday are identical perf tests yet thresholds are almost halved due to interrupt levelling and better cpu allocations )

edit: higher base-clock of 900000 likely effected the normalisation of the current tweak results...

1 Like

@wulfy23

Tried your build and couldn't find any poweroff button. Is it hidden somewhere? Could only find reboot. Didn't want to corrupt the SD card. Had to SSH in to use poweroff command. Any shortcut for this?

1 Like

system > custom_commands > docmd@ARGUMENTS: "poweroff" > click RUN

2 Likes

@wulfy23
Seems like changing wifi to VHT80 or 80mhz channel width kills all wifi, requires reboot.

Is VHT80 working for you?

you may wish to start here then look into this both via the raspberrypi forums or a specific thread on the general forum...

apart from making sure;

  • wpad is enabled/started...
  • wpad-openssl<->wpad... (unlikely to create probs)
  • some alternative defaults... (will not create probs)

nothing about the rpi4 wifi is build specific and most people who can help you likely don't read / post on this thread...

1 Like