When mtd alters the fis partition table it assumes that the first partition
table entry also is the first logical parition table entry. For instance our
table could look like this (irrelevant partitions put aside):
* vmlinux.bin.l7 0xA8710000
* rootfs 0xA8030000
Here mtd would assume vmlinux.bin.l7 being the first partition and use its
address to calculate the size and offset which ultimately leads to a broken
partition table.
This patch alters the behavior by checking what partition has the smaller
address to do the calculations based on that address.
Signed-off-by: Marek Lindner <lindner_marek@yahoo.de>
git-svn-id: svn://svn.openwrt.org/openwrt/trunk@32601 3c298f89-4303-0410-b956-a3cf2f4a3e73
The offset parameter can be used to write the data at the offset
instead of writing it to the beginning of the partition.
Signed-off-by: Marek Linder <lindner_marek@yahoo.de>
git-svn-id: svn://svn.openwrt.org/openwrt/trunk@32600 3c298f89-4303-0410-b956-a3cf2f4a3e73
Pass the mtd_layout via the kernel command line instead.
Also increase the kernel partition size to 1024k, so current kernel can fit in.
Signed-off-by: Daniel Golle <dgolle@allnet.de>
git-svn-id: svn://svn.openwrt.org/openwrt/trunk@32585 3c298f89-4303-0410-b956-a3cf2f4a3e73
Busybox udhcpc dropped support for the -c option, instead it can be emulated by using -x 0x3d:id,
change the dhcp protocol script accordingly and filter all colons from the id while we're at it.
This change supersedes http://patchwork.openwrt.org/patch/1810/
git-svn-id: svn://svn.openwrt.org/openwrt/trunk@32573 3c298f89-4303-0410-b956-a3cf2f4a3e73
On the off chance that the root filesystem's /tmp is used directly as a
temporary directory instead of having a tmpfs mounted over it, it should have
the sticky bit set.
Signed-off-by: Mark Mentovai <mark@moxienet.com>
git-svn-id: svn://svn.openwrt.org/openwrt/trunk@32572 3c298f89-4303-0410-b956-a3cf2f4a3e73
- add_local_domain defaults to 1 and controls whether the local domain is written as search directive to the local resolv.conf
- add_local_hostname defaults to 1 and controls whether A and PTR records are created automatically for the local hostname
These change supersedes http://patchwork.openwrt.org/patch/2207/ and http://patchwork.openwrt.org/patch/2208/
git-svn-id: svn://svn.openwrt.org/openwrt/trunk@32570 3c298f89-4303-0410-b956-a3cf2f4a3e73
This adds a new boolean option, fqdn, to the "config dnsmasq" section of
/etc/config/dhcp. The default is off. When set on, it enables the dhcp-fqdn
option to dnsmasq. dhcp-fqdn causes dnsmasq's DNS server to not resolve
unqualifed local hostnames. The "domain" option is required when using "fqdn".
Local hostnames will remain available for lookup using fully-qualified names.
Signed-off-by: Mark Mentovai <mark@moxienet.com>
git-svn-id: svn://svn.openwrt.org/openwrt/trunk@32569 3c298f89-4303-0410-b956-a3cf2f4a3e73
dnsmasq currently permits dhcp_options to be specified only in "config dhcp"
sections of /etc/config/dhcp. When dnsmasq is providing DHCP service for
multiple subnets and there are multiple "config dhcp" sections without "option
ignore", it makes sense to allow dhcp_options that should apply globally in
the "config dnsmasq" section of /etc/config/dhcp. dhcp_option is a list option.
[jow: rework patch to apply after dhcp-option-force handling got introduced]
Signed-off-by: Mark Mentovai <mark@moxienet.com>
git-svn-id: svn://svn.openwrt.org/openwrt/trunk@32568 3c298f89-4303-0410-b956-a3cf2f4a3e73
Extroot works fine when the target device is specified by a path. It fails
however if the device is specified by UUID (the target partition gets mounted
much later by hotplug hooks). This is because the blkid command is no longer
compiled into BusyBox (since changeset [1]) so it's unavailable for the
preinit phase.
The closest bug report I was able to find is [2], although the reporting person
mentions that /tmp/overlay-disabled showed up which wasn't there in my case.
This patch sets PATH and LD_LIBRARY_PATH environment variables so that the
blkid command installed on the target device can be used by that particular
preinit script.
[1] https://dev.openwrt.org/changeset/26245
[2] https://dev.openwrt.org/ticket/10653
Signed-off-by: Jaroslaw Swierczynski <jarek1701@gmail.com>
git-svn-id: svn://svn.openwrt.org/openwrt/trunk@32567 3c298f89-4303-0410-b956-a3cf2f4a3e73
l2tp_ppp needs to be loaded after pppox, otherwise it ends up like this:
l2tp_ppp: Unknown symbol pppox_ioctl (err 0)
...
during boot.
I also fixed the dependency, it should be pppox rather than pppoe.
Signed-off-by: Daniel Golle <dgolle@allnet.de>
git-svn-id: svn://svn.openwrt.org/openwrt/trunk@32562 3c298f89-4303-0410-b956-a3cf2f4a3e73
testing uclibc changes is tricky because the final gcc tends to miscompile
uclibc code or barf up internal compiler errors.
install binutils into $(TOOLCHAIN_DIR)/initial (without changing the configure
prefix) and copy it from there to $(TOOLCHAIN_DIR)/ so that the initial gcc
can be put into $(PATH) for the uclibc build, even if the final gcc
is already installed.
git-svn-id: svn://svn.openwrt.org/openwrt/trunk@32553 3c298f89-4303-0410-b956-a3cf2f4a3e73
Despite Westwood's theoretical advantages, in nearly
every benchmark we ran last year, TCP cubic won, whether it be
on correct RTT estimates, amount of buffering, responsiveness,
etc. on current hardware and software designs.
(both need timestamps on to work well, besides)
TCP cubic is better maintained and understood than westwood,
also.
While a scenario where westwood would win possibly exists,
there is too much buffering in the wifi stack in particular
at present, to see any improvement.
If you wish to exercise various TCPs under contention,
the current svn head of netperf (2.6) has options to switch
congestion control agorithms on the fly, as does iperf.
git-svn-id: svn://svn.openwrt.org/openwrt/trunk@32514 3c298f89-4303-0410-b956-a3cf2f4a3e73
A year of testing in the cerowrt project shows not using timestamps
to be a very bad idea in nearly any TCP at speeds above a few Mbit.
Lastly sack/dsack help on recovery from larger amounts of packet
loss.
git-svn-id: svn://svn.openwrt.org/openwrt/trunk@32513 3c298f89-4303-0410-b956-a3cf2f4a3e73
