please tell me where i need to remove it?
well, legacy rates(advanced) and channel are in the wireless settings (not sure about noscan) but using nano editing /etc/config/wireless;
# option noscan '1' # option legacy_rates '0' # option channel '8'
( general wifi automated behavior notes below )
what happens is (ONLY if wireless is a default config);
- during firstboot the default wrt.ini contains WIFIAUTOSETUP=1 this 'sets defaults'... but does not enable wireless... ( unless WIFIDEFAULTENABLED=1 )
- Commenting out WIFIAUTOSETUP=1 in your wrt.ini will prevent defaults from being populated...
after firstboot, ( hopefully ) assuming the netifd-wireless.sh was reverted to the original file... your settings should not be modified at all... ( this step, again, was due to 5ghz ap problems for many and newer builds wont change this file anymore as nobody reported any positive benefit from it )
if you wished to have some custom settings ( each firstboot + vanilla config ) these parameters can be set ( again... if you have a non-standard config file your settings should not be touched );
######################### todo-document: just on setup? or always and/or default settings # WIFIDEFAULTENABLED=1 ######################## runs automatically? if config is default ( i.e. setup default settings except enabled above ) # WIFIDEFAULTSSID="ap101" # WIFIDEFAULTPWD="somerandomlongpassword" #!!!must be 9 characters # WIFIDEFAULTCHANNEL="auto" #36 # WIFIDEFAULTMODE="ap" # WIFIDEFAULTHWMODE="11a" # WIFIDEFAULTCOUNTRY="AU"
An additional testing feature... if you have a non-default wireless-config and it is disabled is wifi-admin-boot;
######################### requires non-default and disabled wifi-config # WIFIADMINBOOT=1 #[rc] # WIFIADMINBOOTTIME=300 #[rc]
I have not tested it recently... but it is supposed to switch on wireless for 'duration' each boot... for lockout prevention... or for those with complex ethernet setups as an alternate means to access the device...
What does this give?
uci export dhcp; ls -l /etc/resolv.* /tmp/resolv.*; head -n -0 /etc/resolv.* /tmp/resolv.*
@neil1 just ran some quick tests and the stock-os/driver init issues seem to be prevalent with 11g...
selecting 'Legacy' allows me to establish operational 11g(b?)-AP...
uci export dhcp; ls -l /etc/resolv.* /tmp/resolv.*; head -n -0 /etc/resolv.* /tmp/resolv.* package dhcp config dnsmasq option domainneeded '1' option localise_queries '1' option rebind_protection '1' option rebind_localhost '1' option local '/lan/' option domain 'lan' option expandhosts '1' option authoritative '1' option readethers '1' option leasefile '/tmp/dhcp.leases' option resolvfile '/tmp/resolv.conf.d/resolv.conf.auto' option localservice '1' option cachesize '5000' option sequential_ip '1' option noresolv '1' option doh_backup_noresolv '-1' list server '127.0.0.1#5053' list server '127.0.0.1#5054' list doh_backup_server '127.0.0.1#5053' list doh_backup_server '127.0.0.1#5054' option serversfile '/var/run/simple-adblock.servers' config dhcp 'lan' option interface 'lan' option start '100' option limit '150' option leasetime '12h' option dhcpv6 'server' option ra 'server' option ra_slaac '1' list ra_flags 'managed-config' list ra_flags 'other-config' option ra_management '1' config dhcp 'wan' option interface 'wan' option ignore '1' config odhcpd 'odhcpd' option maindhcp '0' option leasefile '/tmp/hosts/odhcpd' option leasetrigger '/usr/sbin/odhcpd-update' option loglevel '4' lrwxrwxrwx 1 root root 16 Sep 16 14:53 /etc/resolv.conf -> /tmp/resolv.conf lrwxrwxrwx 1 root root 35 Oct 6 03:21 /tmp/resolv.conf -> /tmp/resolv.conf.d/resolv.conf.auto -rw-r--r-- 1 root root 49 Oct 6 03:22 /tmp/resolv.conf.ppp /tmp/resolv.conf.d: -rw-r--r-- 1 root root 89 Oct 6 03:22 resolv.conf.auto ==> /etc/resolv.conf <== # Interface lan nameserver 127.0.0.1 # Interface wan nameserver 127.0.0.1 nameserver ::1 ==> /tmp/resolv.conf <== # Interface lan nameserver 127.0.0.1 # Interface wan nameserver 127.0.0.1 nameserver ::1 ==> /tmp/resolv.conf.d <== head: /tmp/resolv.conf.d: I/O error ==> /tmp/resolv.conf.ppp <== nameserver 126.96.36.199 nameserver 188.8.131.52
You have already
noresolv 1 so the resolv file is not used, but those entries are stored to /tmp/resolv.conf.
option localuse 1 so that the router uses dnsmasq as local system resolver.
Also regarding wireless, make sure that wpad service is enabled and running.
came across this today... seems my assumptions re: usb speeds were incorrect ( well... if we assume openwrt is a general linux distro and 'usb' means usb3+ssd+uasp )...
( so, if there was a need for a single large disk install with data intensive services ~file~ ... seems it would be worth the trouble... but general openwrt runtime apart from boot would likely be negligible )
add this option in config dnsmasq?
cat /etc/config/dhcp config dnsmasq option domainneeded '1' option localise_queries '1' option rebind_protection '1' option rebind_localhost '1' option local '/lan/' option domain 'lan' option expandhosts '1' option authoritative '1' option readethers '1' option leasefile '/tmp/dhcp.leases' option resolvfile '/tmp/resolv.conf.d/resolv.conf.auto' option localservice '1' option cachesize '5000' option sequential_ip '1' option noresolv '1' option doh_backup_noresolv '-1' list server '127.0.0.1#5053' list server '127.0.0.1#5054' list doh_backup_server '127.0.0.1#5053' list doh_backup_server '127.0.0.1#5054' option serversfile '/var/run/simple-adblock.servers'
uci set dhcp.@dnsmasq.localuse="1" uci commit dhcp /etc/init.d/dnsmasq restart
thank you so much it is working now.
Can you help me now with setting up this for guests? no access to lan and limited speed thank you
that would be a question best served by it's own non-community thread...
but unless your premises is minute ( aka, one bedroom apartment )... it's really only useful as a learning exercise and using a separate AP ( running vlans to it from the pi4 ) is the way to go...
the built in rpi4 wifi is ok for for;
- 1-3ish users within
- 2-12m... for 'basic' network tasks...
and/or management purposes... ( have not tested client range but suspect there might be longer range single link use cases in client mode )...
the other thing with the rpi4 wifi... i've noticed using it instantly adds 3degrees celcius to operating temperature ( idle - would be interested to see some temperature graphs under heavy AP load ) ... ( and likely the related respective current draw from the PSU )... considering openwrt already uses significant current for networking/usb operations... that additional wifi burden/temp increase for most, is a complexity best avoided...
why so much ram is being used? how to check what is using my ram?
It looks normal.
OpenWrt caches a few things, hence the 1Gb, 3-400mb also seems fine for generic things.
You can ssh into it and run
opkg install htop, if you dont have it already)
You’ll see what’s using memory, but you have nothing to worry about. I run a few docker containers and a bunch of stuff on top of my RPi OpenWrt, and even after 2 weeks of uptime, it’s generally around 1.75Gb committed, 0.5-1Gb cached 500mb buffered.
Cache is a high-speed storage area on the ram(caches pages from file reading)
Buffer is normal storage area on the ram ( dedicated to cache disk blocks)
Buffers are associated with a specific block device, and cover caching of filesystem metadata as well as tracking in-flight pages. The cache only contains parked file data. That is, the buffers remember what's in directories, what file permissions are, and keep track of what memory is being written from or read to for a particular block device. The cache only contains the contents of the files themselves.
There are also other differences but all-in-all they’re pretty much a normal occurence in any system.
More on this here: http://www.linuxhowtos.org/System/Linux%20Memory%20Management.htm
Guys, i got a problem....
In my try to make my life a little easier, i installed UPNP support for the router. All, good and dandy, but now i got a problem:
Logs grow exponenrtially from the day i activated UPNP, with this message repeating around 10-15 times per second:
Wed Oct 14 08:38:22 2020 daemon.warn miniupnpd: SSDP packet sender [::ffff:192.168.0.1]:38381 (if_index=-1) not from a LAN, ignoring
I searched for bugs reports and the forum and there's no great clues about it. I mostly found that igmpproxy can cause it, but as far i can see, i can't find it installed.
My network is 192.168.1.xxx, so i don't really know what is causing it. Can anybody has any clue how this can be solved or have seen this in the past?
could be a 'modem'... ( trying to be friendly on your WAN interface )...
ip neigh | grep '192.168.0' strace -f -e trace=network -s 10000 -p $(pidof miniupnpd) 2>&1 | grep 192.168.0.1 ### workaround for rogue 192.168.0.x (WILLLOCKYOUOUTIFYOUUSETHATRANGE!) possibly@ INPUT not prerouting? echo "iptables -I INPUT -s 192.168.0.0/24 -j DROP" >> /etc/firewall.user ### or possibly something like iptables -I zone_wan_input -p igmp -s 192.168.0.0/24 -m comment --comment "Drop Chatty External IGMP host" -j DROP
( first guess would have been something ipv6 related )
The first iptables rule worked. The ISP modem is very talkative, even when i disable their built-in DHCP protocol, and converted it to a dumb pppd access concentrator. Seems ISP loves to mess with clients with custom configuration for $$$.
Hi and thanks for your contributions to the community.
got a question.
install the fac image for the first time. and every thing works just fine except the adblock service wont show any Information at the Information panel. after setting everything up.
howdy..., can you double check it's enabled;
luci > system > startup
( or /etc/init.d/adblock enable; /etc/init.d/adblock restart )