<iocampomx>
stintel: Thanks for your recommendation, I was able to set the ethernet mac addr loading it from ROM and adding 1 with "mac-address-increment".
iocampomx has quit [Read error: Connection reset by peer]
iocampomx has joined #openwrt-devel
<iocampomx>
Which is the recommended way to insert a custom firewall rule when building the image? I'm reading this page: https://openwrt.org/docs/guide-user/firewall/firewall_configuration, and clearly explains how to configure the firewall, but once it's already running.
<iocampomx>
So, the /etc/uci-defaults are only executed once, if they return 0 they are deleted, how can I make sure that this script is getting executed every time, to make sure that the SSH access via WAN isn't manually deleted by error? Should I createn /etc/init.d script instead?
<dwfreed>
I mean, just don't delete it?
<iocampomx>
What happen in the next sysupgrade? Are those rule executed again? Or only if I do 'sysupgrade -n'?
<dwfreed>
my comment refers to the ssh rule, not the uci-defaults script
<dwfreed>
and yeah, they'll only run again if you don't keep config during sysupgrade
<dwfreed>
(unless it didn't exist in the previous image)
<iocampomx>
Yes, my question is, what happens if I do a sysupgrade with the SSH firewall rule
<dwfreed>
if you keep config, then the firewall rule will survive sysupgrade
<dwfreed>
if you don't keep config, then uci-defaults wiill run your uci-defaults script to re-add the rule
<iocampomx>
with config, you mean, the whole config of the previous installation, with "sysupgrade -n", right?
<iocampomx>
Is kind of all or nothing, to re-run the uci-default scripts again?
<dwfreed>
if you keep config during sysupgrade, everything in /etc/config will be kept, as well as all the deletions of uci-defaults scripts (scripts that exist in the new image but didn't in the old image will run, but that's it)
<dwfreed>
if you don't keep config during sysupgrade, none of the deletions of uci-defaults scripts would be kept either, so uci-defaults will run again in the boot after the upgrade
<iocampomx>
Got it, and, what happen if in the next upgrade I modify an uci-default script? Will the sysupgrade ignore it because it was previously executed and deleted? Or will it detect the change and re-execute it again?
<dwfreed>
changes to uci-defaults scripts that have already run would be ignored if you keep config during sysupgrade
<dwfreed>
so you just change the script name so it hasn't been run
<iocampomx>
If I do so, I also need to make sure that the "logic being executed" is also considering the possibility that those were previously executed, kind of checking if "something already exists"
<iocampomx>
Or, make the concious decision to upgrade with -n to avoid that risk, with the disadvantage that any custom configuration will be lost
<dwfreed>
I mean, keep both the old script and the new script, and just have the new script do changes to what the old script did
<iocampomx>
Yeah, I'm really thinking long-term/edge cases, for now I will simplify this a little bit. I'm planning to handle this use case with an uci-default script with this content: https://pastebin.com/eyPz7V20
<dwfreed>
iocampomx: instead of calling uci a half dozen times, use batch mode
<dwfreed>
put this before those lines: uci -q batch <<EOF
<dwfreed>
then on each of the other lines, just remove the 'uci '
<iocampomx>
Regarding /etc/config/wireless configuration, I'm using an MT7628AN chipset, at times, I experience connectivity lost, and I'm not able to see the SSID during ~20-30 seconds. The only strange thing I see in logreads is "EAPOL-4WAY-HS-COMPLETED". I've been reading multiple forums. If someone has any feedback/suggestion, and how I should fine-tune the config file, I will really appreciate your help! Thanks
<russell-->
iocampomx: when i'm building custom images, i just capture the changes i've made since the last flash and fold them into the files overlay of the new image and the "don't keep settings" so that a "factory reset" keeps all the changes i want.
<iocampomx>
russell: Thanks for the idea, I don't think that one will scale on my case, as I've 200+ devices. Will be risky to track which one was already upgraded to which version, etc. Given my use case, I think I will got with the "sysupgrade -n" and try to avoid customization as much as I can (or track those specific changes somewhere)
<rua>
Hello. Can bridging across VLAN benefit from HW flow offload of MTK socs?
<dwfreed>
rua: hardware flow offloading is only for LAN to WAN NAT
<rua>
dwfreed: So, non-NAT traffic between LAN and WAN, e.g. bridging, cannot benefit from it?
<dwfreed>
I don't think so
<rua>
dwfreed: Can non-NAT routing, e.g. routing of IPv6, benefit from it?
<dwfreed>
should
<rua>
dwfreed: So can it be concluded that hardware flow offloading can only accelerate works related to routing, but not link-layer works like bridging?
<russell-->
iocampomx: i build in diffutils and have a script that diffs the overlayfs and uci config changes that make capturing local changes workable
<iocampomx>
rusell: Could you please provide more details about which command and in which package is it contained? So that I can play with it.
<iocampomx>
Any idea on how to apply a patch to a kernel module? I'm in particularly refering to package/kernel/mt76. I would like to apply few changes, but the only think I see inside is a Makefile with all its properties (name, pkg source, etc)
<iocampomx>
nbd: Are you around by any chance :) ?
Danct12 has joined #openwrt-devel
<iocampomx>
Found a way, first I was trying to do the whole thing with quilt, but I realized I can also change the PKG_SOURCE_VERSION with the commit I wanted.
Danct12 has quit [Read error: Connection reset by peer]
iocampomx has quit [Read error: No route to host]
<stintel>
heh so they used mac-address-increment which is not mac-base what I suggested
iocampomx has joined #openwrt-devel
Borromini has joined #openwrt-devel
Danct12 has joined #openwrt-devel
Danct12 has quit []
<iocampomx>
If I want to pre-defined a default root password, Should I include /etc/shadow?
<dwfreed>
just set it via uci-defaults
<stintel>
iocampomx: I suggested mac-base, not mac-address-increment.
<iocampomx>
stintel: Oh! I see, let me remove the additional 'mac-address-increment', and append the space + 1
<stintel>
mac-address-increment is what we had before a solution was accepted upstream. mac-base is accepted upstream and so we should aim to use that everywhere possible
<iocampomx>
Testing now...
iocampomx has quit [Ping timeout: 480 seconds]
<rmilecki>
stintel: thanks for recommending upstream solution :)
iocampomx has joined #openwrt-devel
<iocampomx>
stintel: Just to confirm, with <&macaddr_factory_4 2>, should I expect the base mac address to increase by 1 hex digit?
<iocampomx>
Isn't working without mac-address-increment
<stintel>
rmilecki: of course!
<stintel>
rmilecki: can you help iocampomx why it doesn't appear to be working?
<rmilecki>
iocampomx: did you add #nvmem-cell-cells ?
<rmilecki>
in the macaddr_factory_4
<stintel>
rmilecki: thank ;)
<stintel>
thanks*
* stintel
waits for the coffee to be ready
<iocampomx>
#nvmem-cell-cells = <1>; this line? It's commented on the example: https://git.openwrt.org/?p=openwrt/openwrt.git;a=blob;f=target/linux/ramips/dts/mt7621_netgear_r6220.dts;h=146b7ee752ac9dd763f55a5f67ba512412ee8651;hb=f1492fcc091cc5f46cdc4b4fb09eccbbf1b3953b
jkl has quit [Quit: Gone.]
<iocampomx>
Oops, # doesn't mean it's a comment...
<rmilecki>
right, not in .dts files :)
<stintel>
I guess I could look into moving the devices I own to mac-base too
<rmilecki>
iocampomx: looks OK, is it the working one?
<rmilecki>
iocampomx: can you pastebin the one with "nvmem-layout" that doesn't work?
<iocampomx>
It's working, now! It was, perhaps, a syntaxis error I made.
<iocampomx>
Actually, isn't working, here is the error from the console: mtd mtd3: Failed to register NVMEM device.
goliath has joined #openwrt-devel
iocampomx has quit [Ping timeout: 480 seconds]
Danct12 has joined #openwrt-devel
rmilecki has quit [Quit: Konversation terminated!]
rmilecki has joined #openwrt-devel
rmilecki has quit []
rmilecki has joined #openwrt-devel
rmilecki has quit []
rmilecki has joined #openwrt-devel
KGB-2 has quit [Quit: KGB-2]
KGB-2 has joined #openwrt-devel
Borromini has quit [Quit: Lost terminal]
Obi-Wan has quit [Remote host closed the connection]
Obi-Wan has joined #openwrt-devel
Danct12 has quit [Quit: A-lined: This user has been AVIVA-lined!]
Danct12 has joined #openwrt-devel
hitech95 has quit [Remote host closed the connection]
hitech95 has joined #openwrt-devel
colo has quit [Quit: Bye.]
colo has joined #openwrt-devel
<Tapper>
Hi slh Is it worth upgrading from my xg85 to a Sophos SG105 Rev.2 UTM? Is the CPU mutch better?
iocampomx has joined #openwrt-devel
<slh>
Tapper: XG 85 Intel(R) Atom(TM) CPU E3805 @ 1.33GHz with 2 GB RAM vs 105r2 Intel(R) Atom(TM) CPU E3826 @ 1.46GHz, 2GB DDR3 1600 MHz, SSD 64 Go Transcend (TS64GSSD370) - not enough of a difference to really justify buying it, but it's slightly better
<slh>
rev 3 would be a slightly bigger improvement
<slh>
Tapper: new N95/ N100 systems from aliexpress range between 130-250 EUR, depending on the details - worth keeping in mind
<Tapper>
slh thanks mate. I could get the 105 for £40, but I will look for a rev 3 if it's not mutch of a upgrade.
<slh>
40 GBP is a good price, but just not enough of an improvement if you already have the xg85
<slh>
in your case, I'd probably look for sg115 rev3 or newer
Shados has joined #openwrt-devel
<slh>
trustwave, barracuda or nuage networks are also potential alternatives
<Tapper>
slh OK mate thanks will look on ebay.
<slh>
how marginal is the xg85 for your needs (with sqm?)? is it limiting or just tight?
<slh>
Tapper: just for a comparison, my gateprotect fw-7543b with baytrail-d Atom j1900 can achieve ~830 MBit/s in a local test via iperf3
<slh>
j1900 := 4*2.00 GHz (2.42 GHz boost)
<slh>
with sqm/cake
dgcampea has quit [Remote host closed the connection]
dgcampea has joined #openwrt-devel
<rmilecki>
iocampomx: ah, there is mt7621_spi_probe in backtrace
<rmilecki>
iocampomx: it seems mt7621_spi driver can't handle mtd register function returning -EDEFERPROBE
<rmilecki>
iocampomx: i had similar problem with brcmnand
<rmilecki>
i'm not going to spend time checkig every driver now as I can't afford it
<rmilecki>
there is an on-going work to handle NVMEM cells registration independently of mtd devices
<iocampomx>
Got it,
<iocampomx>
for now, I will go back to the "mac-address-increment", is that safe to do meanwhile? Or should I expect any break-change in upcoming releases? I'm trying to understand how closely I should monitor the evolution of this topic
<Tapper>
slh it's limiting. most I get from it is about 395 down. I have a 500 meg connection.
<Tapper>
That's with SQM and a shit load of lists in addblock
<slh>
adblock shouldn't be an issue, that just needs RAM (and you have 2 GB, so rather plenty) - what's limiting is mostly the CPU
iocampomx has quit [Ping timeout: 480 seconds]
Tapper has quit [Ping timeout: 480 seconds]
guidosarducci has quit []
guidosarducci has joined #openwrt-devel
goliath has quit [Quit: SIGSEGV]
iocampomx has joined #openwrt-devel
<iocampomx>
Hi there! I'm performing some networking benchmarks, and I would like to know if the WIFI parameters I've make sense, or if I should fine-tune them? Can you please take a look and provide feedback: https://pastebin.com/4B3UncGh? This is for a MT7628 chipset
iocampomx has quit [Ping timeout: 480 seconds]
iocampomx has joined #openwrt-devel
<dwfreed>
you should generally use channels 1, 6, 11, or 14 (if available) when using 20 MHz width
<dwfreed>
because channel 5 will have you interfering with both channel 1 and channel 6
<dwfreed>
(which means the inverse is true, too; other users on channel 1 and channel 6 will be interfering with you)
<lemmi>
5 will not interfere with 1 beginning with 802.11g and OFDM modulation. in fact, if you are in a country where you have 13 channels available, you can use 1, 5, 9 and 13
<lemmi>
but 1, 6, 11 is the safe bet
<iocampomx>
Got it, besides the channel, is there any other parameter I should fine-tune?
<lemmi>
go with the smallest transmit power, that gives you the coverage you need. hight output power usually causes distortions and lowers available modulation. but ideally... go cable, then a lot of small 5ghz aps.