Default ethernet ip address change.
The 2.6.6 sdk has a few architectural changes that change the way I modify things from the 2.5.3 version. One is the ethernet ip addr was changed from br0 setting to 10.42.0.1 to br-lan 192.168.1.1. In 2.5.3, morse/luci/luci-lib-morseconfig/htdocs/luci-static/resources/tools/morse/morsewizard.js defined DEFAULT_IP_STA = ‘10.42.0.1’;. This isn’t there in 2.6.6. I could put “ifconfig br-lan 10.42.0.1” and “ifconfig br-lan broadcast 10.42.0.255” in ./files/etc/rc.local to change it at end of boot, but by setting it there, the br-lan ip address initially comes up as 192.168.1.1 until rc.local runs. Maybe not a big deal but it seems like a band-aid was applied. What would you suggest as a better place to set the ethernet IP addr in our build to what we’d desire?
-
in 2.5.3 luci there was a DPP push button with a ‘Start’ button to initiate dpp. I can’t find that in 2.6.6. In the quick config menu section, there’s a checkbox for dpp for the halow but no button to initiate dpp? How would you do dpp via luci in 2.6.6? or will it only dpp through the physical push button and not on luci? Is that replaced by the process of going to the client, doing scan, picking the ssid in the list then doing save for that page? It seems halow connects after that process.
-
if I have region as US, halow only connects if I set ap to 12 or 28, but not 44. i.e. ap starts as ch 12, halow connects, change ap to ch28, halow eventually connects, change to 44, no connect. What should I know about the ap and client channels for halow connecting relative to which channels and region selected?
With the IP change, from 2.5 to 2.6 we changed the way this was set from using a uci-defaults file to having it in the target config:
CONFIG_TARGET_PREINIT_IP="10.42.0.1"
CONFIG_TARGET_PREINIT_BROADCAST="10.42.0.255"
(the preinit IP is copied into the normal IP)
If you don’t set this, you get OpenWrt’s default IP (192.168.1.1). This makes the 10.42.0.1 IP specific our EKH boards, and doesn’t accidentally affect others who want to use the SDK. But if you like having 10.42.0.1 (or want some other IP) in a custom build, just set this yourself.
You would never want to set this in rc.local, but always in the uci files, as otherwise your IP may shift around when the network is reconfigured after boot. If you did want to set it in uci files, look into the uci defaults mechanism in OpenWrt.
You should be able to initiate DPP push button from the home page by clicking on the AP card (on the AP side) or on the Uplink card (on the Client side). For full instructions, see the 2.6 user guide section 3.8. Confusingly, DPP push button is not related to selecting DPP on the config page; this is only for the QR Code. In general, the Config page now is only for setting UCI values, and any dynamic interaction (e.g. push button) is done on the Home page.
This is very strange; I have no idea why this would be happening. As long as the regions are the same, the Client should be able to connect to the AP (assuming neither module has the channel disabled). To investigate further, can you run iwinfo wlan0 scan on the Client side to see if it can see the AP, and let us know your current UCI configuration and the logread output from both sides when this is happening?
If I create a file ./files/etc/uci-defaults/86-lan to set the ip addr:
#!/bin/sh
#note: this is like in morse sdk 2.5.3 that used 86-privlan; however, this is just with
#a different filename, device is not br0 but br-lan, and adds ip6assign like 2.6.6 has
[ “$1” != “-f” ] && [ “$(uci -q get network.lan.defaults_applied)” = “1” ] && exit 0
uci set network.lan=“interface”
uci set network.lan.device=“br-lan”
uci set network.lan.proto=“static”
uci set network.lan.ipaddr=“10.42.0.1”
uci set network.lan.netmask=“255.255.255.0”
uci set network.lan.ip6assign=‘60’
uci commit network
uci set network.lan.defaults_applied=“1”
uci commit network
this seems to work; should that be ok? I had actually previously tried the config preinit stuff prior to your mention and the ip after boot was 192.168.1.1, not what I’d specified.
(attachments)
log ch 44 no connect - AP.txt (104 KB)
log ch 44 no connect - client.txt (22.1 KB)
That’s fine. It’s not necessary to do uci commits in this file, and we’ve trying to get rid of things like ‘defaults_applied’ (this is not an OpenWrt standard thing, but something we added), but it should be ok in this context.
Having said that, setting the config vars should definitely just work, as this is the ‘standard’ way to do it and it works fine for us.
If you look at the logs on the AP side, it appears the BCF/module you’re using has Channel 44 disabled:
Sat Jan 4 09:36:34 2025 kern.err kernel: [25106.267877] morse_sdio mmc0:0001:2: Disabling channel (freq: 924000 kHz bw: 8 MHz) due to board-specific rules
This is followed by hostapd complaining a lot about being unable to set the channel. I would suggest talking to the module vendor about this.
Thanks, and that plays right into what I just found out. Right before your response I got this back from silex (note: they said previously we have to use their bcf file, not a morse bcf):
“924MHz is not available, just for your information. The channel is disabled by BCF file. The radio certification did not pass that frequency.”
I asked further, what ch’s are not avail in other bw’s. They said:
1MHz: 902.5 (ch 1) and 927.5 (ch 51)
2MHz: 903 (ch 2) and 927 (ch 50)
4MHz: 906 (ch 8) and 926 (ch 48)
Chs 1 and 2 above are not shown in the dropdown, anyway.
I tried to figure out where the channel/freq combo is populated, but couldn’t. I found ./feeds/ luci/modules/luci-compat/luasrc/view/cbi/wireless_modefreq.htm which I suspect is where that’s populated from, somehow with “iwinfo wlan0 freqlist”. I wondered if it gets channels from the csv files at ./usr/share/morse-regdb/channels.csv and ./www/halow-channels.csv, so I removed all the above channels from those files in the US section and rebooted, but that didn’t remove them from the dropdown.
Can you guide me how that channel list is populated?
Changing those files should have worked (well, it’s the same file, just a symlink). My guess is a browser caching issue if you haven’t built a new image. Try loading in a new browser, or opening the network tab and disabling the cache.
If you’d like disabled channels not to appear in the dropdown, either delete them or change the usable_banff_c column to 0.
Which dropdown are you referring to?
You’re right, I cleared browser cache and they weren’t in there. I am changing ./feeds/morse/morse-regdb/artefacts/repo_channels.csv to make the appropriate channel/bw usable_banff_c column be 0 for US region for each of those channels/bw items that are disabled in silex bcf to build into the project. I never would have known to do that in that way, so I really appreciate when you take extra steps to explain things related to my questions and don’t just give a flat answer to a question.
Which dropdown…
- In Quick Config page: Wireless, Morse Micro HaLow WiFi 802.11ah (radio1), channel dropdown
- That’s the same as Network, Wireless, edit item below the Morse Micro HaLow WiFi 802.11ah row, channel dropdown
- And channel dropdown on wizard page “Setup HaLow Network – AP”
No worries! FYI, the right way technically would be if iwinfo freqlist would report the correct channels when the channels are disabled in the BCF (i.e. it would come from the driver itself), but at the moment that’s hard for us to do. Definitely a sharp edge that we’re trying to address.
What I found was that when I set those config items (which I had actually previously done before your note; your note confirmed I should try it and I know you can change .config manually or through menuconfig) and remove the ./files/etc/uci-defaults/86-lan file from the build, when the image loads, it doesn’t set the ip to 10.42.0.1, it sets it to 192.168.1.1. However, when I add that file (attached), it gives br-lan of 10.42.0.1.
root@ep-hilink-8fbb:/# ifconfig
br-lan Link encap:Ethernet HWaddr 40:D6:3C:01:8F:BB
inet addr:192.168.1.1 Bcast:192.168.1.255 Mask:255.255.255.0
inet6 addr: fe80::42d6:3cff:fe01:8fbb/64 Scope:Link
inet6 addr: fdf8:5799:2d3::1/60 Scope:Global
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:14 errors:0 dropped:0 overruns:0 frame:0
TX packets:23 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:9716 (9.4 KiB) TX bytes:3751 (3.6 KiB)
eth0 Link encap:Ethernet HWaddr 40:D6:3C:01:8F:BB
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:81 errors:0 dropped:4 overruns:0 frame:0
TX packets:23 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:16508 (16.1 KiB) TX bytes:3751 (3.6 KiB)
Interrupt:5
lo Link encap:Local Loopback
inet addr:127.0.0.1 Mask:255.0.0.0
inet6 addr: ::1/128 Scope:Host
UP LOOPBACK RUNNING MTU:65536 Metric:1
RX packets:205 errors:0 dropped:0 overruns:0 frame:0
TX packets:205 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:16920 (16.5 KiB) TX bytes:16920 (16.5 KiB)
After adding file 86-lan back in to project (and leaving the CONFIG items as above):
br-lan Link encap:Ethernet HWaddr 40:D6:3C:01:8F:BB
inet addr:10.42.0.1 Bcast:10.42.0.255 Mask:255.255.255.0
inet6 addr: fe80::42d6:3cff:fe01:8fbb/64 Scope:Link
inet6 addr: fdf0:ff93:4b44::1/60 Scope:Global
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:835 errors:0 dropped:0 overruns:0 frame:0
TX packets:792 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:132101 (129.0 KiB) TX bytes:828686 (809.2 KiB)
(Attachment 86-lan is missing)
Your email system rejected the file “86-lan” I’d attached. Here’s the file in text form:
#!/bin/sh
#note: this is like in morse sdk 2.5.3 that used 86-privlan; however, this is just with
#a different filename, device is not br0 but br-lan, and adds ip6assign like 2.6.6 has
[ “$1” != “-f” ] && [ “$(uci -q get network.lan.defaults_applied)” = “1” ] && exit 0
uci set network.lan=“interface”
uci set network.lan.device=“br-lan”
uci set network.lan.proto=“static”
uci set network.lan.ipaddr=“10.42.0.1”
uci set network.lan.netmask=“255.255.255.0”
uci set network.lan.ip6assign=‘60’
uci commit network
uci set network.lan.defaults_applied=“1”
uci commit network
It’s fine to set it via uci-defaults, but what the ‘preinit’ thing should do is create /etc/board.d/99-lan-ip with your new IP in it. So if you want to debug, you can check the contents on your board. For example:
# cat /etc/board.d/99-lan-ip
. /lib/functions/uci-defaults.sh
logger -t 99-lan-ip "setting custom default LAN IP"
board_config_update
json_select network
json_select lan
json_add_string ipaddr "10.42.0.1"
json_add_string netmask "255.255.255.0"
json_select ..
json_select ..
board_config_flush
Hmmm…the only 99-lan* anything anywhere, it only has /etc/board.d/99-default-network which contains. I searched the project, which includes staging dir, but nothing. And the preinit stuff is in .config. I embedded the screenshot in this reply, whether your system handles that or not, we’ll find out.
Yes, sorry about the issues you’re having with attachments. It seems like discourse is not quite smart enough to handle that well via email, or at least we don’t have it configured to do so. You may have to visit the website to get those to work.
But, I’ve finally realised I made a mistake in what I gave you earlier - you also need to set:
CONFIG_TARGET_DEFAULT_LAN_IP_FROM_PREINIT=y
Managed not to copy/paste the 3rd line from our configs. Sorry!
Ah, thanks. I did this, removed the ./files/etc/uci-defaults/86-lan file I’d created for the build and when the device booted, br-lan was 10.42.0.1. Good. However, there was no file like you mentioned before, 99-lan-ip. It wouldn’t even find it anywhere: find -iname -lan, except it found my old one in /rom/etc/board.d/86-lan and nowhere else. I figured it needed a little cleanup to remove that so I did “make clean”, built and 99-lan-ip showed up while eliminating traces of my 86-lan.
Another 2.6.6 vs 2.5.3 diff:
A change to 2.6.6 was that wireless.default_radio1.mode is set to ‘ap’ but wasn’t set in 2.5.3. This change was made in ./feeds/morse/netifd-morse/lib/wifi/morse.sh.
However, wireless.default_radio0.mode=‘ap’ was in 2.5.3 and 2.6.6. That’s fine, but the problem I’m running into for 2.6.6 is from a bare image before anything gets initialized for region or wizard or anything, I need to determine using the halow radio if that is setup as a client or ap. I figured out in 2.5.3 I can make sure the board isn’t an ap by using this setting. By having 2.6.6 make to be ap before it even gets setup is a problem.
What I’m doing to alleviate this is to put a copy of that morse.sh here: ./files/lib/wifi/morse.sh, with the line commented out: set wireless.default_radio${devidx}.mode=ap.
The other place that radio mode is set to ap is in ./package/kernel/mac80211/files/lib/wifi/mac80211.sh.
This is where radio0 mode is set to ap in 2.5.3, but it doesn’t set radio1 mode (and that’s good). It seems I’m able to keep the setting for .mode=ap in this file and it won’t set radio1 mode, only radio0 mode.
Can you help me understand why default_radio1 mode was also set to be ap in 2.6.6 in that morse.sh file?
In 2.6.6, I can’t find the ‘shell’ selection from the luci menu items. Was this removed or if not, how do you get it in luci in 2.6.6? If removed, just curious why and would it be easy enough to add back?
Go to ‘Services → Terminal’ for the shell.
Re the mode changes, it’s fine to change the hotplug (i.e. /lib/morse/wifi.sh) to not create an AP by default. I guess the idea is you want to check to see if you’ve setup the wifi? However, I think a better way to do this would be to check if the wifi-device is disabled.
The reason this script is changed to set up an AP by default to be consistent with the normal OpenWrt behaviour (which sets up a single AP on all wifi-devices on hotplug, as you noticed occurs in mac80211.sh). My apologies that it’s caused a problem here.
-
The only option under Services is ser2net (see attached). How do I get ‘terminal’?
-
The mode changes goes back to thread on needing /etc/init.d/hostap-leds which is used instead of “hostapd_cli_s1g -i wlan0 -a /lib/functions/clientconnected.sh”. I don’t want this to do anything if it’s not an ap. This is determined by the halow radio (radio1) mode. If it comes up as an ap by default before going thru the wizard to make it a client, it’s running a service that’s meant only for the ap, not the client. Thus, I don’t care about the wifi radio (radio0), just the halow radio (radio1).
hostap-leds is determining this by: “result=$(uci show wireless.default_radio1.mode | grep “‘ap’”)” -
Thanks for the detail. At least I found a way to work around it for our need. Short of that, if you know a better way in the architecture to accomplish that, I’m all ears.
(attachments)
