In linux there is commonly the option to disable ipv6 in the boot environment (CMD ipv6.disable=1). Is such possible in TO and if so how/where?
I am aware of net.ipv6.conf.all.disable_ipv6 = 1 but that is just ipv6 routing and does not prevent modules from creating ipv6 sockets
Turris Omnia uses u-boot as a boot loader. You can change boot arguments using fw_setenv and print them by fw_printenv. But before first usage you have to set default u-boot configuration using serial connection from u-boot cli (otherwise you will see message: Warning: Bad CRC, using default environment).
that is trifle bit complicated, not having a serial laying around. Is there no easier way to manipulate a simple boot environment variable?
Perhaps I will try to construct the /etc/fw_env.config manually with cat /proc/mtd, dmesg and grep -R CONFIG_ENV_SIZE
I suppose if that succeeds it would be adding ipv6.disable=1 to bootcmd=
uboot-envtools are not configured with correct default environment that is why you have to use serial line to save real default u-boot environment from uboot binary. You can probably try to override it from user space using fw_setenv. Following is probably default configuration (pulled from one of my testing omnias):
baudrate=115200
bootargs=earlyprintk console=ttyS0,115200 rootfstype=btrfs rootdelay=2 root=b301 rootflags=subvol=@,commit=5 rw
bootcmd=i2c dev 1; i2c read 0x2a 0x9 1 0x00FFFFF0; setexpr.b rescue *0x00FFFFF0; if test $rescue -ge 1; then echo BOOT RESCUE; run rescueboot; else echo BOOT eMMC FS; run mmcboot; fi
bootdelay=3
ethact=neta2
ethaddr=d8:58:d7:00:1a:1d
fdt_high=0x10000000
initrd_high=0x10000000
mmcboot=setenv bootargs "$bootargs cfg80211.freg=$regdomain"; btrload mmc 0 0x01000000 boot/zImage @; btrload mmc 0 0x02000000 boot/dtb @; bootz 0x01000000 - 0x02000000
rescueboot=i2c mw 0x2a.1 0x3 0x1c 1; i2c mw 0x2a.1 0x4 0x1c 1; mw.l 0x01000000 0x00ff000c; i2c write 0x01000000 0x2a.1 0x5 4 -s; setenv bootargs "$bootargs omniarescue=$rescue"; sf probe; sf read 0x1000000 0x100000 0x700000; bootz 0x1000000
stderr=serial@12000
stdin=serial@12000
stdout=serial@12000
If you contact me mid next week I might be able to give you check if this is really default configuration. I don’t have time to do so now. Also I have never tested fw_setenv without first setting environment from uboot it self. Probably what you want to do is first set all default values and then do some changes.
Change you probably are looking for is to append your option to bootargs option.
But be aware that you are playing with booting process. If you screw something up then you can end up with not booting Omnia. You would need serial cable to fix it. Non of standard rescue procedures will work because they are all based on u-boot.
adding
sysctl -w net.ipv6.conf.all.disable_ipv6=1
sysctl -w net.ipv6.conf.default.disable_ipv6=1
to /etc/rc.local should do the trick
or to /etc/sysctl.conf or to file in /etc/sysctl.d/
Like I mentioned in my initial post I am aware of it and it just preventing ipv6 routing but not disabling ipv6
then what would net.ipv6.conf.all.forwarding do?
please try again
note:
all.disable = disable for existing interfaces
default.disable = disable for future/new interfaces
you need both
@hadc net.ipv6.conf.all.disable_ipv6=1 - disables routing but not ipv6
net.ipv6.conf.all.forwarding=1 - disables forwarding but not routing and not ipv6
From package/boot/uboot-envtools/files/turris-omnia.cfg · master · Turris / openwrt · GitLab used /dev/mtd0 0xC0000 0x10000 0x40000 in /etc/fw_env.config. But that is still producing Bad CRC.
And for some reason the -R option is removed grep in busybox and thus a dereference-recursive for CONFIG_ENV_ is not feasible.
Sounds a good idea. Still trying to figure out the potential syntax to disable ipv6 @bootcmd=. Documentation is rather sparse. Somwhere it was suggested:
in uboot command shell, adding “ipv6.disable=1” into the value of bootargs variable
fw_setenv bootargs ipv6.disable=1
First of all. Read uboot documentation. Second, fw_setenv is syntax where first argument is variable name and second argument is value. Next you have to see uboot like a syslinux for example. It just loads kernel, initramfs and device tree. Then it passes command line arguments to kernel and runs it. So whole variable bootargs is used as a command line for Linux. So you want to append your option rather then override it.
Also as I wrote. In default configuration is not saved and that is why you are getting CRC error. When no configuration is saved then uboot uses built-in configuration. When you write something to that configuration then that CRC error should go away but also uboot will probably read just your configuration. That is why you should first set it to default value.
And as last point. -R in grep is not there because we have very very old busybox. You can use find with xargs instead. But I missed what you are trying to do with CONFIG_ENV_?
Note: Just for completeness. This is what it should rather look like:
fw_setenv bootargs 'earlyprintk console=ttyS0,115200 rootfstype=btrfs rootdelay=2 root=b301 rootflags=subvol=@,commit=5 rw ipv6.disable=1'
Of course don’t forget to set also all other variables. I am just not sure if default value would be used if not set in configuration but I think it wouldn’t (I just have not ever tested it and don’t remember if it’s documented somewhere).
Been reading [OpenWrt Wiki] Das U-Boot Environment, the part
Accessing U-Boot environment variables in Net Console
Some devices seem not to have the uboot_env section and the environment appears with an offset in the section containing uboot (/dev/mtd0) here. In the latter case expect that the environment address (offset) is a multiple of Flash sector size.
In the subsection
Determine CONFIG_ENV_OFFSET, CONFIG_ENV_SIZE, and CONFIG_ENV_SECT_SIZE
You can search for it by issuing a grep search in the base directory of the OpenWrt tree.
# grep -R CONFIG_ENV_SIZE
Hence, I am trying to figure out the offset of uboot_env after cat /proc/mtd produced
dev: size erasesize name
mtd0: 00100000 00010000 "U-Boot"
mtd1: 00700000 00010000 "Rescue system"
To my understanding it is possible to write directly from the uboot shell fw_setenv if fw_printenv is not producing a Bad CRC. Any idea how to figure that out without grep -R?
ran find / | xargs CONFIG_ENV with no result, which might be find with xarg being less potent than grep -R
@cynerd Of course I managed in the meantime to brick the router, which was predictable but good for one’s education, and just ordered a usb ttl uart cable (or whatever the correct namefication is), anyway one of those rx/tx/gnd. Do I need to upload (or is it flashing?) a fresh uboot environment/binary, e.g. uboot-turris-omnia-uart-spl.kwb?
What I really do not undestand is this whole magic with a cable and binary un/wrapping just to access/manipulate the boot environment. No such thing with a common linux distro, just straight forward bootloader editing there.
That configuration is not on the router. It’s compile time configuration. It’s set in OpenWRT sources for uboot build system. And in Turris 3.10 there should already be correct configuration set for fw tools (I fixed it few months back).
Unless you wrote to invalid section it should be enough to power up router, break boot by pressing enter and that way accessing uboot cli. Then you just have to do env default -a -f and saveenv.
If you managed to also corupt uboot then recovery will more complicated.
Also you should have read upstream uboot documentation. OpenWRT is more or less digest and is more about caviats in OenWRT than general guide.
In compare with normal distro, changing uboot configuration is more in line with changing bios configuration. In case of TO uboot serves purpose of both bootloader and “bios”. Well you can also use it as efi like bios and chain boot standard bootloader (like syslinux). But that is not what is done on TO.
Thank you for the feeback and explanation!
Certainly there are reasons to combine bios and and bootloader but for changing a simple boot argument it seems a lot of hoops having to jump through.
Will know once the uart converter cable is at hand, hoping its quality will suffice the purpose
The uart converter worked out (required some driver download/installation in WIN 10) as well as the router’s bootenv recovery, the router now back in operation with ipv6 disabled in the kernel. Thank you for the comprehensive guidance!
To my understanding flashing the router with the omina medkit is also flashing the spi and is resetting the bootenv to default, correct?
With ipv6 disabled in the kernel the lighttpd sockets are gone and thus neither Foris nor LuCI is accessible.
What is the problem you want to solve by disabling ipv6? IMHO today you need a good excuse to do that.
there are plentiful of reasons (neither problem solving nor excuses) from my perspective to disable ipv6 but this thread was not meant to discuss the philosophy of ip versions but merely seeking assistance with the topic’s subject. And such has been achieved.
you also have to set net.ipv6.conf.default.disable_ipv6=1 as @hadc already wrote.
NO, this doesn’t only disable routing!
some programs nowadays use ipv4-compatible ipv6-sockets as far as i know.
it’s a technical question, no philosophy.
although you don’t want to hear this, more and more internal networks disable IPv4.
Had a discussion about this with folks developing network apps, such as vpn. net.ipv6.conf.all/default.disable_ipv6=1 is diabling ipv6 routing in the kernel but not ipv6. That is proven with ipv6 sockets still being created. Only ipv6.disable=1 removes ipv6 from the kernel entirely.
for completeness bootenv ipv6.disable_ipv6=1 will keep the ipv6 stack functional but will not assign ipv6 addresses to any of the network devices
and sure why not? It is matter of necessity and/or preference. But again that is not the topic of this thread.