working after manually restarting dnsmasq and https-dns-proxy in services.
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
reinstall https-dns-proxy or remove the top half of that hotplug file...
run this to sort of find out;
netifd-interfaceinfo.sh
and this
1 Like
can someone try to compile/add these package on our raspberrypi4, it would be useful to bypass internet censorship in my country
install v2ray and see how you go... (might be snapshot only)... it's a little large to include by default unless 5+ people want a specific variant for it...
I already tried v2ray, but it's outdated and has no support for the VLESS protocol.
VLESS is more efficient and fast than VMESS 
Hopefully, someone would be interested in it to try.
1 Like
yeah... well if two build users want it... I don't mind including a firstboot setup script and INI option... but someone else would need to maintain the script... (and firstboot/setup download would obviously take place over normal connection... possibly not favourable for something like this)
1 Like
netifd-interfaceinfo.sh
INTERFACE L3_DEVICE UP AVAILABLE AUTOSTART DYNAMIC PENDING PROTO
======================================================================================================
IPTV eth1 up avail auto nodynamic nopending static
accessmodem eth1 up avail auto nodynamic nopending static
guest br-guest up avail auto nodynamic nopending static
lan br-lan up avail auto nodynamic nopending static
loopback lo up avail auto nodynamic nopending static
wan pppoe-wan up avail auto nodynamic nopending pppoe
1 Like
Ok I am going to do it now.
rm /root/.firstboot.99-kickit
[root@network /]# rm /root/.firstboot.99-kickit; /etc/custom/firstboot/99-kickit
rm: can't remove '/root/.firstboot.99-kickit': No such file or directory
INTERACTIVE 99-kickit> network restart [sleep 9] ...
INTERACTIVE 99-kickit> ifaces_pending: wan [wait:26]
INTERACTIVE 99-kickit> ifaces_pending: wan [wait:25]
INTERACTIVE 99-kickit> ifaces_pending: wan [wait:24]
INTERACTIVE 99-kickit> ifaces_pending: wan [wait:23]
INTERACTIVE 99-kickit> pending> no-pending
INTERACTIVE 99-kickit> notup> no-notup
INTERACTIVE 99-kickit> all done!... [no /tmp/.kickit]
wow... that's really good under 5 seconds... thought pppoe might have taken longer...
1 Like
Has anyone tested the packet forwarding rate of the RPi 4 with different packet sizes?
With a DFRobot, @geerlingguy got 76,656 pps for 64-byte packets.
The rate needed to route a gigabit of 64-byte packets is 1488095.
At 1500-byte packets, he got a packet rate of 73291 pps, which is close but still doesn't saturate a gigabit connection - 1000^3 / (1538*8) == 81274 pps.
Is my math wrong? Can somebody tell me what I'm missing, perhaps @moeller0 or @dlakelan?
Is it possible the DFRobot carrier solution is actually inferior to the UE300 adapter somehow?
Well, maybe hping is not the ideal traffic source for such a test... IMHO running iperf2/iperf3/netperf/hping/... on the device that is to be tested is valid for servers and clients, but for routing performance, I consider it cleaner not to terminate the traffic on the device under test.
But @64bytes -> 64+38 = 102B ethernet framesize, so according to your correct calculation for full MTU frames, I see 1000^3 / (102*8) = 1225490.19608 pps which still is a far cry from 75,828....
Back-to-back each 102B packet would take:
(1/(1000^3 / (102*8))) * 1000^2 = 0.816 Microseconds
on the wire, but Jeff requested 15 microseconds send intervals (-i u15)... limiting the maximum theoretical rate to 1000^2/15 = 66666.667 pps. Which is closer to what he actually saw (also indicating that hping is not taking -i u15 literally). In addition his 75,828 pps number is counting each packet twice, so are aggregates for both directions... so 177372/4.6 = 38559.130 pps or 174405/4.6 = 37914.130 pps and not 75,828 pps. (At least for a router the minimal pps of both direction seems the best measure as that correlates with "routing" functionality over a single interface, for a router with multiple interfaces reporting both directions independently also seems more relevant then the sum)
Not sure I agree with his conclusion from this test.
Also did anybody perform the same test with the onboard ethernet adapter or an UE300, tp see whether there are differences in performance? And lastly, I agree that a Gbps-capable rputer SHOULD be able to route even minimal sized packets at line-rate, but realistically loads with saturating minim packet sizes will be super rare in reality, so does that really matter?
1 Like
The frame size is 64 in total, quoting him: "64-byte packets (28 headers + 36 bytes data size)".
Btw, why 38 for headers? You have 20 for IP and 8 for ICMP up until data.
The rest of your comment is interesting and raising good points.
Anyway, it'd be interesting if somebody tested it with his Pi with a USB nic (hping with different data sizes).
As for the saturating with mini packets, however unlikely, I like to be ready for every scenario 
Because the payload is 36, see man hping3:
-d --data data size
Set packet body size. Warning, using --data 40 hping3 will not generate 0 byte packets but protocol_header+40 bytes. hping3 will display packet size in‐
formation as first line output, like this: HPING www.yahoo.com (ppp0 204.71.200.67): NO FLAGS are set, 40 headers + 40 data bytes
So 36B payload + 8B ICMP header + 20B IPv4 header + 38B Ethernet frame header (the same reason why you did the 1538 in 1000^3 / (1538*8) instead of just taking the 1500 ethernet payload into account).
Here is what constitutes the 38 byte ethernet overhead:
7 Byte Preamble
- 1 Byte start of frame delimiter (SFD)
- 12 Byte inter frame gap (IFG)
- 4 Byte Frame Check Sequence (FCS)
- 6 Byte (dest MAC)
- 6 Byte (src MAC)
- 2 Byte (ethertype)
= 7 + 1 + 12 + 4 + 6 + 6 + 2 = 38 Byte
Please note that the interframe gap/IFG is actually not used to transmit bytes, but the NIC will not send anything for the the same duration it would take to transmit 12 bytes, so we can simply convert that silence into its equivalent bytes.
I hope that clarifies.
let me know how that goes...
1 Like
Hi Wulfy23: your latest Build(stable) is also having a Bug(regarding Theme).
I want to have Bootstrap Dark, but it refuses to display in Dark.
Here is the Proof of it.
Is it just me or anyone else is also having the same issue ??? other than that i find this testing Package to be almost stable for daily driver. If you release a stable Version, can i just simply upgrade the Version to latest stable one ? i tried doing so with the previous version to the current one. and i ended up losing Internet Connection...
Thanks for your Hardwork and reply.
1 Like
had the issue also... no time to look at it properly yet...
yeah... i'm not having too many issues with it... someone reported intermittent / sporadic network hangs... and i've personally seen the odd browser funniness... but not something where i'd say... this is a 'problem'... if I was gamining/using voip etc. it might be another story
not too sure what you've done there... all builds are interchangable... all depends on the finer steps... how you did it, with what settings, how long you waited, any fancy programs you might have etc. etc.
(your screenshot says 1.0.7-3 which is 'release' yet you refer to it as 'stable' so something is not adding up - but 'stable' is a bit confusing as it will normally mean 'release' in this build 'stable' up until now is always 'best/most recent master')
personally i've never had this issue...
Hi, i used sys image of the latest build and tried to update it in the Browser without saving the settings( that is fresh install). to be sure i did flash the file 2 times in the Webbrowser and waited say 5-7 Minutes. Even after that i had no Internet connection. Hence i had to write the Factory inage of the latest build first flashed on SD card and then update the Sys image using Webbrowser update function.
Did i do the Update in the correct order at the beginning ?
1 Like
yeah... on this build i've never tested not saving settings... so your a pioneer...
while it will work if you read the instructions for some finer details... i've never recommended this method in any README... but do so from time to time in this thread where a user may not be able to use a command line... (or I specify a certain image or don't want to regurgitate all the common upgrade advice in the second post)
you should be using [flash] or the commands recommended...
you bring up a good point about not saving settings tho'... I believe the github readme docs state somewhere you should flash a new factory if that's the case... but... i will put that on my list to do more testing of...
my guess in your case... is that not saving settings was indeed problematic for some unknown reason... ( or maybe it worked hence the reason no network came up, hard to say )
here it is... not super easy to find https://github.com/wulfy23/rpi4/blob/master/misc/guides/abc123.md
using sysupgrade -n has never been tested you'd assume that
it would leave you with something similar to a factory install
although i suspect there would be a glitch or two... lucklily...
zapping a new factory to an sdcard is an equivalent workaround
these comments were written very early on in the build... so its taken ~15 months for someone to get tripped up (and report it)
Hmm, then why do you have the Sys images ??? if that is the case you should have had only Factory images for burning them onto SD card right ??
How do you flash those sys images please tell me. As far as i know sys image is for updating from within the browser. This is what i have learnt from flashing Openwrt onto Routers.
To your surprise 
i did just like how i described it above and still i am having a perfectly working Openwrt setup with all the functions which i want working without a problem.
all builds are interchangable...
what do you mean from this statement of yours ?
1 Like
switch to the bootstrap or argon theme and click [flash] in the top bar... if you want a different flavour change UPGRADEsFLAVOUR in /root/wrt.ini ( luci > system > startup > advanced startup )
(other two/three methods luci or command line are listed in the 2nd post... as is the statement above)
good question... in most cases... I handle upgrade/downgrade incompatibilities... so not keeping settings is unneeded...
where you will have a particular problem is if a package is required for firstboot internet function (there are some posts on this thread about adguard and https-dns-proxy before it was in the build... people changed dnsmasq settings and upgraded... and naturally dns probably wont work if the post-installed package is not in the new build)
having said the above... odd new stuff does come up from time to time... ( package xyz was never tested / accounted for etc. etc. )
other way around... once you use a factory once... you'll barely need one again unless something major goes wrong... i've used a factory about 1 time in 12 months while testing ~500 new builds
(but 3-5 users have mentioned broken OS's and needing to use a factory over that time... they were often brave and using 'current' flavour or I pushed a glitch down to 'stable')
for command line users... I implemented a 'summary' param 2 months ago...
did not really document it but may be of use to someone...
############### [root@dca632 ../_HTTPS-DNS-DEBUG 52°]# rpi-sysup-online.sh summary
########################################################## rpi-sysup-online.sh release check
flavour:release online:1.0.7-3[older] onsys:3.5.315-7
##########################################################
localversion=1.0.7-3 datebuilt=20211117-1742 FILESREVISION=27003 VARIANTpkg=fullest
release=21.02.1
buildversion=r16325-88151b8303
kernelinfo=5.4.154-1-deb453573a04e7a02726b2659a2a3363
########################################################## rpi-sysup-online.sh stable check
stable[minor-update] online:3.5.315-11(3.5.315-7)
##########################################################
localversion=3.5.315-11 datebuilt=20211214-2214 FILESREVISION=27129 VARIANTpkg=fullest
release=snapshot
buildversion=r18325-66f9ed1684
kernelinfo=5.10.83-1-e3933f3329212a6b56ca2b0553406b10
########################################################## rpi-sysup-online.sh current check #[active]
current[minor-update] online:3.5.315-11(3.5.315-7)
##########################################################
localversion=3.5.315-11 datebuilt=20211214-2214 FILESREVISION=27129 VARIANTpkg=fullest
release=snapshot
buildversion=r18325-66f9ed1684
kernelinfo=5.10.83-1-e3933f3329212a6b56ca2b0553406b10
########################################################## rpi-sysup-online.sh testing check
no testing build available