I think this is his point, mate: You work hard (in isolation), but don't
communicate.
If you want to avoid emails that smell like farts to you, why not tell
people what's going on?
On 2 October 2014 17:51, John Crispin wrote:
> nice rant, what happened at mignight that you got so angry that you
Apparently yes, Bruno. Just asking for more communication while at the same
time even commending the devs for their hard work, as Etienne did, seems to
justify being insulted.
Personal sensibilities aside this has been a bone of contention for a long
time. Here just a couple of examples:
https://l
Really, John?
Personal insults through direct emails?
On 2 October 2014 18:14, John Crispin wrote:
> until now i considered you "one of the reliable crowd" and just
> reasserted to "yet another troll"
>
>
> On 02/10/2014 07:01, Hanno Schupp wrote:
> >
Could this be back ported to AA?
Kind Regards
Hanno Schupp
On 11/03/2013, at 8:23 AM, Dmytro wrote:
> Index: target/linux/ar71xx/files/arch/mips/ath79/mach-tl-wr841n-v8.c
> ===
> --- target/linux/ar71xx/files/arch/m
Any help and pointers on how to build such a x86 image is appreciated.
Thanks
Hanno Schupp
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
The changes never got included but they works fine on 2.6 kernel trunk version.
On trunk that means you can only go up to revision 31xxx - up until the point
that atheros target was switched to 3.2 kernel. Then these changes do no longer
fit and compile. And in backfire there is an earlier 2.6 k
thank you for taking the initiative.
Kind Regards
Hanno Schupp
On 10/11/2012, at 12:11 AM, Jonathan Bither wrote:
> Good morning list,
>I was writing to ask if there is a current maintainer for the Atheros
> target that I may contact.
> The reason that I ask is because I was con
Hi Jonathan
Will this fix the Engenius boot issue? Will non-Engenius still boot? And what
about LEDs? Will they stop working on some or all devices? Please advise
Kind Regards
Hanno Schupp
On 22/11/2012, at 11:29 AM, Jonathan Bither wrote:
> Karl,
>I remember attitude adjustme
Dear All,
I am trying to get coova-chilli 1.3.0 supported, but the compile process is
failing. Usually it is just a matter of updating the version number nad md5
checksum to get the upgrade happening, like so:
#
# Copyright (C) 2007-2010 OpenWrt.org
#
# This is free software, licensed under the GN
Hi,
Which skills or services are you looking for?
Kind Regards
Hanno Schupp
On 1/02/2013, at 6:02 AM, "Tanya Kotwall" wrote:
> Hi all, I’m working on a cloudcomputing project for a very well funded
> company.. not sure if anyone’s free to take on a new project?
>
>
Could this be applied to AA as well, please?
On 5/02/2013, at 1:59 PM, David Hutchison wrote:
> We utilize many Routerboard 751's and discovered that our latest batch
> of RB751's would not initialize the wireless radio. We have determined
> Mikrotik has changed where the mac address was locat
Can this please Nd back ported to AA?
Kind Regards
Hanno Schupp
On 14/02/2013, at 4:26 AM, Alexander Stadler wrote:
> From: Alexander Stadler
>
> fix factory image creation for dir-825-c1
>
> Signed-off-by: Alexander Stadler
> ---
> diff -urN a/target/linux/ar71x
Can this please be back ported to AA ?
Kind Regards
Hanno Schupp
On 14/02/2013, at 2:33 AM, Alexander Stadler wrote:
> From: Alexander Stadler
>
> fix switch-config for dir-825-c1
>
> Signed-off-by: Alexander Stadler
> ---
> diff -urN a/target/linux/ar71xx/base-f
For same of stability, that's why.
Kind Regards
Hanno Schupp
On 14/02/2013, at 6:08 AM, Alexander Stadler wrote:
> Hi!
>
> Don't know if we backport models for Attitude Adjustment? (Model not
> supported on attitude adjustment, so its not that specific patch alon
I am working on improved support for the Skyline SL-R7205 Wireless 3G
Router (hence my previously submitted patches)but have struck a dead end on
a particular issue. I found that during boot the device acts like dumb
switch, allowing traffic to pass through for a short time. I attached
serial cable
questions about that but wiki and forum are
silent about the specifics around this.
> On 13/01/2014, at 11:50 pm, John Crispin wrote:
>
> Am 1/13/14 11:39 AM, schrieb Hanno Schupp:
>> I am working on improved support for the Skyline SL-R7205 Wireless 3G
>> Router (hence my
Somebody seems to have done all the hard work already merging Ralink I boot
modifications back into uboot bootloader code for the rt2880/rt305x platform:
https://gitorious.org/wive-rtnl-ralink-rt305x-routers-firmware/wive-rtnl-ralink-rt305x-routers-firmware/source/e568932211ea59ff3b09bf2839859de3
einstall, rebranding and others) are discussed
> individually by e-mail."
>
> --
> Michel
>
> Le 14/01/2014 00:06, Hanno Schupp a écrit :
>> Somebody seems to have done all the hard work already merging Ralink I boot
>> modifications back into uboot bootloader code for the rt28
Thank you John and Michel for taking the time to explain. Much appreciated.
Based on your comments and some research I found a resolution to the issue
that in the end is quite simple.
Whether the Ralink extension of UBoot is hackish or not Is not for me
to judge but in their defense the issue of t
> On 16/01/2014, at 9:43 pm, Michel Stempin wrote:
>
> Hi Hanno,
>
> Le 16/01/2014 04:18, Hanno Schupp a écrit :
>> Thank you John and Michel for taking the time to explain. Much appreciated.
>> Based on your comments and some research I found a resolution to th
Hi,
In the current approach there is an inherent limitation in that the
uci-default scripts run before the application init.d scripts are run. While
this is desirable for many situations, it is an issue in those cases you
need to have the network up, switch recognised, wifi driver identified etc.
In the status overview I see the statement
<%=pcdata(model or "?")%>
which displays the detected router model, if detected. So far so good.
Three questions:
1) How can I access the same model data from the bash shell?
2) What other useful data is accessible under pcdata?
3) Which program does this
\n]+)") or
luci.util.pcdata(fs.readfile("/proc/diag/model")) or
nixio.uname().machine or
system
return system, model, memtotal, memcached, membuffers, memfree, bogomips
end
Remaining question:
I have not checked the nixio code but I
Signed-off-by: Your name
Index: Makefile
===
--- Makefile(revision 27980)
+++ Makefile(working copy)
@@ -8,12 +8,12 @@
include $(TOPDIR)/rules.mk
PKG_NAME:=coova-chilli
-PKG_VERSION:=1.2.5
+PKG_VERSION:=1.2.8
PKG_RELEASE
The update is required as the old filename
usb-modeswitch-data-20110705.tar.bz2 is no longer hosted on
http://www.draisberghof.de/usb_modeswitch/
BTW, the two openwrt.org backup servers do not hold either the old
usb-modeswitch-data-20110705.tar.bz2 nor the new
usb-modeswitch-data-20110805.tar.bz2
Signed-off-by: Your name
Index: Makefile
===
--- Makefile(revision 28007)
+++ Makefile(working copy)
@@ -8,12 +8,12 @@
include $(TOPDIR)/rules.mk
PKG_NAME:=usb-modeswitch
-PKG_VERSION:=1.1.8
+PKG_VERSION:=1.1.9
PKG_RELEA
Pleasure. While you are at it, could you please also release the upgrade of
coova-chilli from 1.2.5 to 1.2.8 I submitted about the same time as the
USB-modeswitch patches?
Kind Regards
Hanno Schupp
Connect Consulting Services
Chillifire is a trademark owned by CCS
On 29/08/2011, at 12:12
Hi Felix,
Why do you recommend that revision? Is it particularly stable?
Please advise
-Original Message-
From: openwrt-devel-boun...@lists.openwrt.org
[mailto:openwrt-devel-boun...@lists.openwrt.org] On Behalf Of Felix Fietkau
Sent: Saturday, 17 September 2011 7:29 p.m.
To: OpenWrt Deve
we be looking
for in terms of regression testing?
Please advise
Kind Regards
Hanno Schupp
Connect Consulting Services
Chillifire is a trademark owned by CCS
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org
base-files/etc/uci-defaults/network and
target/linux/ar71xx/base-files/etc/defconfig/* for example?
Please advise
Regards
Hanno
-Original Message-
From: Felix Fietkau [mailto:n...@openwrt.org]
Sent: Saturday, 22 October 2011 12:08 p.m.
To: OpenWrt Development List
Cc: Hanno Schupp
S
Dear all,
I have recently switched from backfire to trunk. This forced a change
from madwifi to ath5k for atheros platforms. I also compile and test
firmware on ar71xx, ramips and brcm47xx.
I notice that on ar71xx and ramips the actual router/board is
identified in /proc/cpuinfo. Luci in trunk is
Hi Felix,
I understand the rationale of the change from busybox to ntpd in
standard. Does that mean though that the ntpd package has to be chosen
in the .config file or is ntpd really integrated into busybox, making
the ntpd client package obsolete?
Please advise.
Regards
Hanno Schupp
Previosly on madwifi using a special uci config parameter the polarisarion
on Nanostation and Nano Loco plus polarisation on Loco could be set easily
(refer to lines 138 to 196 in
https://dev.openwrt.org/browser/trunk/package/madwifi/files/lib/wifi/madwifi.sh
)
Trunk selects ath5k for atheros and
that
piece of code does not exist in mac80211 and as I said ar71xx cannot even
differentiate between nano and nano loco and bullet.
Cheers
Hanno Schupp
On 15/11/2011, at 1:47 AM, Daniel Golle wrote:
> Hi Hanno!
> I'm working on that for the ALL0258N, going to post a draft lat
Hi,
is there really no answer to this? Device detection has taken a real
hit from madwifi to ath5k, and since the latter is the default in
trunk, I woul have thought there is some way forward or workaround. No
thoughts at all?
Cheers
Hanno
Dear all,
I have recently switched from backfire to t
Seems to me it is the 'vendor id' plus the 'subsys id' of the pci
information that makes all the difference and allows detection for
devices with fixed wifi cards.
Is this information of 'vendor id' and 'subsys id' visible somewhere
in 'user land' i.e on the command line, possibly with additional
Hi,
Can anyone advise how to switch to the external antenna on a Nanostation 2
when using the ath5k selected as standard wireless driver in trunk? The old
option antenna external
in the wireless config file which was available in Madwifi is no longer
supported in ath5k. The sysctl and gpios to com
Interesting. The exact same thing is occurring on my D-link DIR600 B2, a ramips
based router.
Kind Regards
Hanno Schupp
Connect Consulting Services
Chillifire is a trademark owned by CCS
On 25/11/2011, at 11:35 AM, Nerijus Baliunas
wrote:
> Hello,
>
> Wifi MAC is correct, corre
Hi Mark, that is interesting. I am battling with some device recognistion
issues myself. What is that ' art/caldata area' you mention?
Can you access the data from the command line after Boot? I guess I am
asking how can you access the data in 'userland', i.e. in shell scripts?
Cheers
Hanno
-
ted
Kind Regards
Hanno Schupp
Connect Consulting Services
Chillifire is a trademark owned by CCS
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Thank you for the order.
The P2P filter is installed by default but not activated. You can do that
within the firmware.
Kind Regards
Hanno Schupp
Connect Consulting Services
Chillifire is a trademark owned by CCS
On 6/12/2011, at 1:30 PM, Nerijus Baliunas
wrote:
> On Mon, 5 Dec 2011
Hi jow
I just upgraded to latest trunk 29871 and discovered that the iwinfo
improvements introduced in 29421 which display hardware name, and txpower
offset apparently still only apply to the atheros platform if the outdated
madwifi driver is used. If using ath5k the standard wireless driver fo
Hi,
I cannot get collectd-mod-iwinfo to work for the proprietary wl0 drivers.
They work fine on ath5k and ath9k.
Before I try further, does collectd-mod-iwinfo support wl0 or do I need to
fall back to collectd-mod-wireless?
___
openwrt-dev
Thanks Jow,
I had a look at /trunk/package/iwinfo/Makefile and the IWINFO_BACKENDS
section seems to define wl driver as required target if a Broadcom kernel
module is loaded.
I do not understand Makefile at all, so I do not understand what else needs
to be done to 'wl must be enabled at build tim
Hi jow,
Thanks for following up.
Here the outputs:
root@Router00177962:/tmp# iwinfo wl0 info
wl0 ESSID: "Chillifire Hotspot"
Access Point: 00:1D:7E:E7:96:D4
Type: wl HW Mode(s): 802.11bg
Mode: Master Channel: 3 (2.422 GHz)
Tx-Power: 24 dBm Link Q
Hi Jonathan,
Thank you for this patch. I am currently using a simplified version of what
you are doing in an approach that relies on compiling a specific version of
the firmware for the different models
(https://dev.openwrt.org/attachment/ticket/6202/100-board-trunk-b18541.patch
) as it hard codes
useful vendor and device ids for Engenius which would be great to
add. Your thoughts?
Cheers
Hanno Schupp
-Original Message-
From: Jonathan Bither [mailto:jonbit...@gmail.com]
Sent: Monday, 6 February 2012 3:39 p.m.
To: Hanno Schupp; openwrt-devel@lists.openwrt.org
Subject: Re
That is correct, but I could imagine he (and others) are confused by the
fact that the buildroot does not generate a pico-m image, just a bullet-,
nano-m, and a rocket-m. The bullet-m image will work on the pico-m, but
there is nothing that tells users.
Another 'not-so-nice-thing' by the way is th
This change was a definite improvementfor legacy atheros; as one can see
below the hardware is now properly detected by iwinfo.
What is not so nice is the txpowerlist. As I had reported last year, the
system reports 27dBm regardless which hardware is used.
Fon, Ubiquiti, Engenius on atheros p
> Done. Does 30dBm mean it has 10dBm power offset?
Yes, the Pico 2 and 2 HP is essentially a Bullet 2 or Bullet 2 HP in a
case. It even has Bullet 2 or Bullet 2 H printed on the circuitboard.
Funny.
> Does it indeed find no IDs? In this case I'd be interested in a copy of
> the boardconfig partit
ot usually loaded on the
devices I have access to. Please advise.
On 20 February 2012 23:46, Hanno Schupp wrote:
> I assume you want mtd5:
>
> root@Router002722400:~# cat /proc/mtd
> dev: size erasesize name
> mtd0: 0004 0001 "u-boot"
> mtd1: 0001
Oh yes, and any hint on finding pci information on a ar71xx platform in Openwrt?
On 21 February 2012 07:07, Hanno Schupp wrote:
> Here goes ...
>
>
> On 21 February 2012 06:56, Jo-Philipp Wich wrote:
>> -BEGIN PGP SIGNED MESSAGE-
>> Hash: SHA1
>>
>>
Hi jow,
Thanks for your efforts.
I can confirm the Picostation M2 is now properly recognised.
The Pico2 and Pico2HP however are not recognised.
There is also a regression in so much as the Nanostation2 is no longer
recognised as such (see below).
I can help out with a dump of the Nanostation
Signed-off-by: Hanno Schupp
Index: src/iwinfo_lib.c
===
--- src/iwinfo_lib.c(revision 30668)
+++ src/iwinfo_lib.c(working copy)
@@ -350,8 +350,8 @@
{ VENDOR_UBNT, "SR71", 0x168c, 0x00
Signed-off-by: Hanno Schupp https://lists.openwrt.org/mailman/listinfo/openwrt-devel
There is a reasonably far advanced port to these boards on the forum,
which is unfortunately based on the 2.9.36 kernel, which now has been
wiped.
I wanted to port this to 3.2 but cannot find machtype.h file anywhere
under 3.2.
Any pointers where the machine type definition went from 2.9 to 3.2?
upported by the 750 profile? There were
>> questions about access to the nand storage via the processor gpio pins, but
>> this may be resolved by now? Please advise.
>>
>> PS: happy to supply dmesg and or EEPROM and other dumps if this is helpful.
>>
>> Hanno S
I am not a developer, but I can tell you the ath9k is for b/g/n cards,
so that may be the reason. You should use either ath5k or madwifi
driver. Personally I found many issues with ath5k integration into
openwrt still unresolved in terms of card and device recognition and
am consequently in the pro
(me included).
Cheers
On 28 February 2012 09:34, Jonathan Bither wrote:
> Hanno,
> Do we happen to have a list of known issues so that we can work on getting
> them resolved instead of reverting back to mac80211?
>
>
> On 02/27/2012 03:15 PM, Hanno Schupp wrote:
>>
>
Dear ar71xx developers,
the new support of the AR8327 switch chip with revision 31011
(generic: ar8216: add support for the AR8327 chip) opens up the
possibility to support the whole family of Mikrotik RB75x routers:
RB750 (already supported by OpenWrt), RB750G(superseded by RB750GL),
RB750GL, RB7
Sure, 450G is supported for a long time. No idea about the 435g, give if a try
and let us know...
On 23/03/2012, at 7:38 PM, Weedy wrote:
> On 22/03/12 11:14 PM, Hanno Schupp wrote:
>> My last good image is on the Mikrotik rb450g is 30857. 31037 no longer
>> works. I hav
:04 a.m.
To: OpenWrt Development List
Subject: Re: [OpenWrt-Devel] Mikrotik Routerboard 450G - access to LAN ports
broken
On 2012-03-23 8:13 AM, Gregory Finch wrote:
> On 2012-03-22 8:14 PM, Hanno Schupp wrote:
>> My last good image is on the Mikrotik rb450g is 30857. 31037 no
>>
@juhosg
I tested the new support for the rb750gl that you implemented in 31025. It
worked fine for me and I could not detect any anomalies. You say 'Initia;l
support'; why initial? As I say, seems go to go to me. Well done and thank
you.
What I did notice is that the leds on the rb750 no lo
Great collaboration on these two fantastic routers on the openwrt forum:
https://forum.openwrt.org/viewtopic.php?id=32320
Above all kudos to aryufan. Well done and thank you everyone else who
contributed.
To-Do: LED for wlan is not yet activated
Signed-off-by: Hanno Schupp hanno.sch
Hi, can we get this applied please, before it goes stale?
Thanks
On 31 March 2012 23:22, Hanno Schupp wrote:
> Great collaboration on these two fantastic routers on the openwrt forum:
> https://forum.openwrt.org/viewtopic.php?id=32320
>
> Above all kudos to aryufan. Well done a
ot yet activated
To-Do: TxPower over 20dBm (RB751U) or 22dBm (RB751G) are not accepted by the
router
Signed-off-by: Hanno Schupp <mailto:hanno.sch...@gmail.com>
hanno.sch...@gmail.com
Index: target/linux/ar71xx/files/arch/mips/ath79/
:42:24 Hanno Schupp wrote:
>> Great collaboration on these two fantastic routers on the openwrt forum:
>> <https://forum.openwrt.org/viewtopic.php?id=32320>
>> https://forum.openwrt.org/viewtopic.php?id=32320
>>
>> Above all kudos to aryufan. Well done and tha
(RB751G) are not accepted by
the router
Signed-off-by: Hanno Schupp hanno.sch...@gmail.com
Index: target/linux/ar71xx/files/arch/mips/ath79/mach-rb750.c
===
--- target/linux/ar71xx/files/arch/mips/ath79/mach-rb750.c (revision
Was that patch now received unmangled?
If so, can it be applied, please?
Thanks
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
I am at a loss then what to do. I even went to the length of installing alpine
on my pc just for the purpose of sending one email.
Why is this so hard? This makes porting openwrt to a new router model look easy
in comparison. I sent it to myself as a copy and it looked completely normal to
me.
) are not accepted by
the router
Signed-off-by: Hanno Schupp hanno.sch...@gmail.com
Index: target/linux/ar71xx/files/arch/mips/ath79/mach-rb750.c
===
--- target/linux/ar71xx/files/arch/mips/ath79/mach-rb750.c (revision 31152
Apologies fr my frustrated rant ;-)
Thanks everyone for your advice.
One last try in-line. Is that any better?
Please advise
On 6 April 2012 10:01, Hanno Schupp wrote:
> Great collaboration on these two fantastic routers on the openwrt forum:
> https://forum.openwrt.org/viewtopic.
Great. Thanks.
Mental note:
Ctrl-R in Alpine is what made the difference.
On 6 April 2012 10:02, Jo-Philipp Wich wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> Hi,
>
> this one is fine...
>
> Now we still have to wait fore gabor to review it :)
>
> ~ Jow
> -BEGIN PGP SIGNATURE-
Should I then? If that is what I 'should do', why does
https://dev.openwrt.org/wiki/SubmittingPatches not tell me about it?
On 6 April 2012 20:20, Florian Fainelli wrote:
> Hi,
>
> Le 04/05/12 23:36, Hanno Schupp a écrit :
>
>> I am at a loss then what to do.
I am curious as I was not even aware that you could tell the compile process to
use one uClib erosion or another. I thought that was fixed through the
toolchain compile process. How do you get the buildroot process to use a
certain uClib version then?
Kind Regards
Hanno Schupp
Connect
expected, a known issue? Any suggestion to debug
and analyse the issue? I am at a loss.
Kind Regards
Hanno Schupp
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
see
https://dev.openwrt.org/ticket/6819).
I suspect recent changes to the rtl8366 drivers (30842-30857) introduced this
regression. I logged a ticket on https://dev.openwrt.org/ticket/11312
Kind Regards
Hanno Schupp
On 20/04/2012, at 10:00 AM, Hanno Schupp wrote:
> Dear All,
>
>
Any chance these patches will be backported to backfire?
Please advise.
-Original Message-
From: openwrt-devel-boun...@lists.openwrt.org
[mailto:openwrt-devel-boun...@lists.openwrt.org] On Behalf Of
openwrt-devel-requ...@lists.openwrt.org
Sent: Tuesday, 29 June 2010 10:00 p.m.
To: openwrt-
Dear All,
I am implementing a script for n2n with dhcp on supernode support and in
this context questions about dnsmasq, resolv.conf and resolv.conf.auto.
On /etc/init.d/network start the system seem to look for DNS servers on WAN,
obtain a dhcp lease etc. When that happens /tmp/resolv.conf.auto i
Fantastic. Thank you very much for your comments. This makes things a lot
clearer.
I conclude from what you wrote that:
- Adding DNS server ip addresses to /tmp/resolv.conf by adding them to the
DNS_SERVER variable at the top of the /etc/init.d/dnsmasq script is useless
- they will never be read o
Hi,
Which Senao router/board are you referring to? Lookign either at the Senao
or the EnGenius product, there is no reference to an EAP7660D router or
board. Did you mean the EAP3660 by any chance? That is the closest product
code I could find. Could you respond with a link, please? Thanks.
-O
issues to get it released, let the community know what
these issues are so we can contribute to an effort to resolve this.
I trust this is taken how it is meant, an offer of support to move
things along in everyone's interest.
Kind Regards
Hanno S
from rc3 to final, and
associated an offer of support (yet to be responded to).
Regards
Hanno Schupp
-Original Message-
From: Alexandros C. Couloumbis [mailto:a...@aventurine.gr]
Sent: Wednesday, 27 October 2010 2:44 a.m.
To: Hanno Schupp
Cc: openwrt-devel@lists.openwrt.org
Subject
Updating n2n to this release allows the inclusion of the mac address to the
edge command, which in turns allows the linking of a dhcp server to the
supernode, and thus IP address assignment.
(For background see http://wiki.freifunk.net/N2n) Tested in bakfire, trunk
brcm-2.4., ar71xx and atheros.
S
This brings coova up to speed - tested in backfire and trunk.
Signed by: hanno.sch...@gmail.com
remove root/packages/net/coova-chilli/patches/001-readd-macauth.patch
Index: Makefile
===
--- Makefile (revision 23710)
+++ Makefile (w
Yes?
Kind Regards
Hanno Schupp
Connect Consulting Services
Chillifire is a trademark owned by CCS
On 30/10/2010, at 10:14 PM, Roger Hardiman wrote:
>
>
> From: Hanno Schupp
> Sent: 29 October 2010 11:03
> To: OpenWrt Development List
> Subject: [OpenWrt-Devel] [pa
Anything wrong with this? I thought this was pretty trivial change.
Could this be released, if there is no issue, please?
On 29 October 2010 23:03, Hanno Schupp wrote:
> Updating n2n to this release allows the inclusion of the mac address to the
> edge command, which in turns allows the l
Since the linkage of Luci 0.10 to 10.03.1rc4 there is now an empty button
(no text in it) which points to cgi-bin/luci/servicectl.
When clicked a white page appears with the word 'finished'
Why is it there and how can I make it go away?
___
openwrt-devel
here the relevant code in the header of the page:
http://192.168.12.1/cgi-bin/luci/;stok=494bf87cbc2529258e1e7d0c793f6567/mini/>">Essentials
http://192.168.12.1/cgi-bin/luci/;stok=494bf87cbc2529258e1e7d0c793f6567/admin/>">Administration
http://192.168.12.1/cgi-bin/luci/;stok=494bf87cbc2529258e1e7
Thanks, it appears simple enough to fix:
<%
for k,node in pairs(tree.nodes) do
- if node.title and not node.hidden then %>
+if node.title and not node.hidden and k ~= 'servicectl' then %>
class="active"<%end%>
href="<%=controller%>/<%=k%>/"><%=node.title%><%
end
In the default collection for Luci in trunk and now since 24955 also in
backfire the mini (Essentials) menu has gone.
I have are requirement for it and have brought it back by adding the
dependency in the luci Makefile and adding the package back into the.config
file. Easy enough.
However, what I
You are right. My apologies.
On 19 January 2011 06:54, Jo-Philipp Wich wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> Hi.
>
> I just tried it in the SDK and mini is still default if present.
> Are you sure you didn't just clear the cache in /tmp ?
>
> ~ Jow
> -BEGIN PGP SIGNATU
As per heading. See below.
make distclean did not fix it
last known revision tested positive: r6745, although looking at track *6749
is the culprit itself, as it deletes luci/branches/luci-0.10/build/
i18n-po2lua.pl in backfire, which is needed for compilation*
PS: is there a possibility to pull
I have reopened https://dev.openwrt.org/ticket/8263
LuCi incomplete: collecting Data...as the exact same problem still occurs
onlatest backfrie 25029.
Some additional observation:
When using Chrome a javascript alert pops up saying 'unupported node -4'
When confirming OK a second alert pops up:
'
Yes, here goes:
/*
* xhr.js - XMLHttpRequest helper class
* (c) 2008-2010 Jo-Philipp Wich
*/
XHR = function()
{
this.reinit = function()
{
if( window.XMLHttpRequest ) {
this._xmlHttp = new XMLHttpRequest();
}
Not for these web pages specifically.
I have some custom controller, cbi and views, that all work fine.
I use the standard openwrt.org theme, but have replaced the header and
footer with my own .htm files and replaced the css file with my own.
Is that what you refer to by templates?
-Original
Fantastic. That was it.
The header.htm was based on the header.htm of luci 0.9, which had other js
files included like the dropdown, but not xhr.
Suggestion: add some documentation to the luci page that gives required
elements ( the create your own theme page )
Offer: I volunteer updating that pa
While the page seems to work, the js alert is still fire in Chrome, but in
Chrome only
-Original Message-
From: openwrt-devel-boun...@lists.openwrt.org
[mailto:openwrt-devel-boun...@lists.openwrt.org] On Behalf Of Jo-Philipp
Wich
Sent: Thursday, 20 January 2011 9:42 a.m.
To: OpenWrt Develo
Google Chrome 8.0.552.237
That is a Linux build
Yes, clearing browser cache does not resolve the issue.
On 20 January 2011 10:29, Jo-Philipp Wich wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> Which chrome build/release exactly? Can you rule out any caching issues?
> -BEGIN PG
Luci seems to assume that there has to be one ethx kind of inderface
declaration and tries to 'fix it' when none is found.
However, consider this standard /etc/config/network file ofr tp-link 914nd
v3
config interface loopback
option ifname lo
option protostatic
opti
1 - 100 of 121 matches
Mail list logo
