Re: [OpenWrt-Devel] WRT1900AC - Available firmwares ?
On Thu, 2015-01-08 at 14:36 -0200, Fernando Frediani wrote: Hi all, Does anyone here have a Linksys WRT1900AC (that fiasco that suppose to be the new generation of WRT54G) ? Yes and I like it. As Imre Kaloz says Marvel recently released updated driver source. It seems to me the major hold up was the development approach used in the beginning. I think it cost quite a bit of time on what was essentially a false start. Now Marvel have chosen to update (pretty much re-wrote) the driver with the goal of having it accepted into the upstream kernel. It arrears to have much less code than the original and what looks to me like ugly hacks to other core OpenWrt subsystems to make the old driver work are no longer needed so the maintenance burden should be much less for all concerned. Over all very good news. Ian ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] Install .pc files of Python
Hi, .pc files are not copied to the install directory, so python (as a library) cannot be checked from configure.ac by PKG_CHECK_MODULES. It caused problem during the port of Zorp GPL to OpenWrt. Possible solution is attached. Best regards, Szilárd Pfeiffer From b7a1ac80ec6536b165e2f1db61d4bac9a086c4bf Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Szil=C3=A1rd=20Pfeiffer?= coro...@pfeifferszilard.hu Date: Thu, 27 Nov 2014 23:19:40 +0100 Subject: [PATCH] Install .pc files from Python package. --- lang/python/Makefile | 7 ++- 1 file changed, 6 insertions(+), 1 deletion(-) diff --git a/lang/python/Makefile b/lang/python/Makefile index 954612f..6039b2e 100644 --- a/lang/python/Makefile +++ b/lang/python/Makefile @@ -104,7 +104,7 @@ endef define Build/InstallDev $(INSTALL_DIR) $(STAGING_DIR)/mk/ - $(INSTALL_DIR) $(1)/usr/include/ $(1)/usr/lib/ + $(INSTALL_DIR) $(1)/usr/include/ $(1)/usr/lib/ $(1)/usr/lib/pkgconfig $(INSTALL_DIR) $(1)/usr/lib/python$(PYTHON_VERSION)/ $(INSTALL_DATA) ./files/python-package.mk $(STAGING_DIR)/mk/ $(CP) \ @@ -115,6 +115,11 @@ define Build/InstallDev $(PKG_INSTALL_DIR)/usr/lib/libpython$(PYTHON_VERSION).so* \ $(1)/usr/lib/ $(CP) \ + $(STAGING_DIR_HOST)/lib/pkgconfig/python.pc \ + $(STAGING_DIR_HOST)/lib/pkgconfig/python2.pc \ + $(STAGING_DIR_HOST)/lib/pkgconfig/python-$(PYTHON_VERSION).pc \ + $(1)/usr/lib/pkgconfig + $(CP) \ $(PKG_INSTALL_DIR)/usr/lib/python$(PYTHON_VERSION)/config \ $(1)/usr/lib/python$(PYTHON_VERSION)/ endef -- 1.9.1 ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] [PATCH v2 uqmi] Add command for listing device capabilities
Signed-off-by: Sławomir Demeszko s.demes...@wireless-instruments.com
---
Sorry, it seems my compiler doesn't suport -Wtautological-compare option,
and I was not warned about this. This condition could be removed, but
as I read it is unspecified if enums are signed or unsigned, it depends
on compiler, so I cast it to signed for comparison. I can't test it,
but should get rid of the warning.
commands-dms.c | 53 +
commands-dms.h | 2 ++
2 files changed, 55 insertions(+)
diff --git a/commands-dms.c b/commands-dms.c
index a677052..563b6d9 100644
--- a/commands-dms.c
+++ b/commands-dms.c
@@ -7,6 +7,59 @@ static struct {
char* puk;
} dms_req_data;
+static void cmd_dms_get_capabilities_cb(struct qmi_dev *qmi, struct
qmi_request *req, struct qmi_msg *msg)
+{
+ void *t, *networks;
+ int i;
+ struct qmi_dms_get_capabilities_response res;
+ const char *radio_cap[] = {
+ [QMI_DMS_RADIO_INTERFACE_CDMA20001X] = cdma1x,
+ [QMI_DMS_RADIO_INTERFACE_EVDO] = cdma1xevdo,
+ [QMI_DMS_RADIO_INTERFACE_GSM] = gsm,
+ [QMI_DMS_RADIO_INTERFACE_UMTS] = umts,
+ [QMI_DMS_RADIO_INTERFACE_LTE] = lte,
+ };
+ const char *service_cap[] = {
+ [QMI_DMS_DATA_SERVICE_CAPABILITY_NONE] = none,
+ [QMI_DMS_DATA_SERVICE_CAPABILITY_CS] = cs,
+ [QMI_DMS_DATA_SERVICE_CAPABILITY_PS] = ps,
+ [QMI_DMS_DATA_SERVICE_CAPABILITY_SIMULTANEOUS_CS_PS] =
simultaneous_cs_ps,
+ [QMI_DMS_DATA_SERVICE_CAPABILITY_NON_SIMULTANEOUS_CS_PS] =
non_simultaneous_cs_ps,
+ };
+
+ qmi_parse_dms_get_capabilities_response(msg, res);
+
+ t = blobmsg_open_table(status, NULL);
+
+ blobmsg_add_u32(status, max_tx_channel_rate, (int32_t)
res.data.info.max_tx_channel_rate);
+ blobmsg_add_u32(status, max_rx_channel_rate, (int32_t)
res.data.info.max_rx_channel_rate);
+ if ((int)res.data.info.data_service_capability = 0
res.data.info.data_service_capability ARRAY_SIZE(service_cap))
+ blobmsg_add_string(status, data_service,
service_cap[res.data.info.data_service_capability]);
+
+ if(res.data.info.sim_capability == QMI_DMS_SIM_CAPABILITY_NOT_SUPPORTED)
+ blobmsg_add_string(status, sim, not supported);
+ else if(res.data.info.sim_capability ==
QMI_DMS_SIM_CAPABILITY_SUPPORTED)
+ blobmsg_add_string(status, sim, supported);
+
+ networks = blobmsg_open_array(status, networks);
+ for (i = 0; i res.data.info.radio_interface_list_n; i++) {
+ if ((int)res.data.info.radio_interface_list[i] = 0
res.data.info.radio_interface_list[i] ARRAY_SIZE(radio_cap))
+ blobmsg_add_string(status, NULL,
radio_cap[res.data.info.radio_interface_list[i]]);
+ else
+ blobmsg_add_string(status, NULL, unknown);
+ }
+ blobmsg_close_array(status, networks);
+
+ blobmsg_close_table(status, t);
+}
+
+static enum qmi_cmd_result
+cmd_dms_get_capabilities_prepare(struct qmi_dev *qmi, struct qmi_request *req,
struct qmi_msg *msg, char *arg)
+{
+ qmi_set_dms_get_capabilities_request(msg);
+ return QMI_CMD_REQUEST;
+}
+
static const char *get_pin_status(int status)
{
static const char *pin_status[] = {
diff --git a/commands-dms.h b/commands-dms.h
index 925aea3..a370425 100644
--- a/commands-dms.h
+++ b/commands-dms.h
@@ -1,4 +1,5 @@
#define __uqmi_dms_commands
\
+ __uqmi_command(dms_get_capabilities, get-capabilities, no,
QMI_SERVICE_DMS), \
__uqmi_command(dms_get_pin_status, get-pin-status, no,
QMI_SERVICE_DMS), \
__uqmi_command(dms_verify_pin1, verify-pin1, required,
QMI_SERVICE_DMS), \
__uqmi_command(dms_verify_pin2, verify-pin2, required,
QMI_SERVICE_DMS), \
@@ -18,6 +19,7 @@
__uqmi_command(dms_reset, reset-dms, no, QMI_SERVICE_DMS) \
#define dms_helptext \
+ --get-capabilities: List device
capabilities\n \
--get-pin-status: Get PIN verification
status\n \
--verify-pin1 pin: Verify PIN1\n \
--verify-pin2 pin: Verify PIN2\n \
--
1.9.1
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] [PATCH uqmi] Add missing option for getting tdma signal strength
Signed-off-by: Sławomir Demeszko s.demes...@wireless-instruments.com
---
commands-nas.c | 5 +
1 file changed, 5 insertions(+)
diff --git a/commands-nas.c b/commands-nas.c
index be06ee4..831e3f4 100644
--- a/commands-nas.c
+++ b/commands-nas.c
@@ -152,6 +152,11 @@ cmd_nas_get_signal_info_cb(struct qmi_dev *qmi, struct
qmi_request *req, struct
blobmsg_add_u32(status, snr, (int32_t)
res.data.lte_signal_strength.snr);
}
+ if (res.set.tdma_signal_strength) {
+ blobmsg_add_string(status, type, tdma);
+ blobmsg_add_u32(status, signal, (int32_t)
res.data.tdma_signal_strength);
+ }
+
blobmsg_close_table(status, c);
}
--
1.9.1
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] [PATCH uqmi] Add command for listing device capabilities
Signed-off-by: Sławomir Demeszko s.demes...@wireless-instruments.com
---
commands-dms.c | 53 +
commands-dms.h | 2 ++
2 files changed, 55 insertions(+)
diff --git a/commands-dms.c b/commands-dms.c
index a677052..fcb4b93 100644
--- a/commands-dms.c
+++ b/commands-dms.c
@@ -7,6 +7,59 @@ static struct {
char* puk;
} dms_req_data;
+static void cmd_dms_get_capabilities_cb(struct qmi_dev *qmi, struct
qmi_request *req, struct qmi_msg *msg)
+{
+ void *t, *networks;
+ int i;
+ struct qmi_dms_get_capabilities_response res;
+ const char *radio_cap[] = {
+ [QMI_DMS_RADIO_INTERFACE_CDMA20001X] = cdma1x,
+ [QMI_DMS_RADIO_INTERFACE_EVDO] = cdma1xevdo,
+ [QMI_DMS_RADIO_INTERFACE_GSM] = gsm,
+ [QMI_DMS_RADIO_INTERFACE_UMTS] = umts,
+ [QMI_DMS_RADIO_INTERFACE_LTE] = lte,
+ };
+ const char *service_cap[] = {
+ [QMI_DMS_DATA_SERVICE_CAPABILITY_NONE] = none,
+ [QMI_DMS_DATA_SERVICE_CAPABILITY_CS] = cs,
+ [QMI_DMS_DATA_SERVICE_CAPABILITY_PS] = ps,
+ [QMI_DMS_DATA_SERVICE_CAPABILITY_SIMULTANEOUS_CS_PS] =
simultaneous_cs_ps,
+ [QMI_DMS_DATA_SERVICE_CAPABILITY_NON_SIMULTANEOUS_CS_PS] =
non_simultaneous_cs_ps,
+ };
+
+ qmi_parse_dms_get_capabilities_response(msg, res);
+
+ t = blobmsg_open_table(status, NULL);
+
+ blobmsg_add_u32(status, max_tx_channel_rate, (int32_t)
res.data.info.max_tx_channel_rate);
+ blobmsg_add_u32(status, max_rx_channel_rate, (int32_t)
res.data.info.max_rx_channel_rate);
+ if (res.data.info.data_service_capability = 0
res.data.info.data_service_capability ARRAY_SIZE(service_cap))
+ blobmsg_add_string(status, data_service,
service_cap[res.data.info.data_service_capability]);
+
+ if(res.data.info.sim_capability == QMI_DMS_SIM_CAPABILITY_NOT_SUPPORTED)
+ blobmsg_add_string(status, sim, not supported);
+ else if(res.data.info.sim_capability ==
QMI_DMS_SIM_CAPABILITY_SUPPORTED)
+ blobmsg_add_string(status, sim, supported);
+
+ networks = blobmsg_open_array(status, networks);
+ for (i = 0; i res.data.info.radio_interface_list_n; i++) {
+ if (res.data.info.radio_interface_list[i] = 0
res.data.info.radio_interface_list[i] ARRAY_SIZE(radio_cap))
+ blobmsg_add_string(status, NULL,
radio_cap[res.data.info.radio_interface_list[i]]);
+ else
+ blobmsg_add_string(status, NULL, unknown);
+ }
+ blobmsg_close_array(status, networks);
+
+ blobmsg_close_table(status, t);
+}
+
+static enum qmi_cmd_result
+cmd_dms_get_capabilities_prepare(struct qmi_dev *qmi, struct qmi_request *req,
struct qmi_msg *msg, char *arg)
+{
+ qmi_set_dms_get_capabilities_request(msg);
+ return QMI_CMD_REQUEST;
+}
+
static const char *get_pin_status(int status)
{
static const char *pin_status[] = {
diff --git a/commands-dms.h b/commands-dms.h
index 925aea3..a370425 100644
--- a/commands-dms.h
+++ b/commands-dms.h
@@ -1,4 +1,5 @@
#define __uqmi_dms_commands
\
+ __uqmi_command(dms_get_capabilities, get-capabilities, no,
QMI_SERVICE_DMS), \
__uqmi_command(dms_get_pin_status, get-pin-status, no,
QMI_SERVICE_DMS), \
__uqmi_command(dms_verify_pin1, verify-pin1, required,
QMI_SERVICE_DMS), \
__uqmi_command(dms_verify_pin2, verify-pin2, required,
QMI_SERVICE_DMS), \
@@ -18,6 +19,7 @@
__uqmi_command(dms_reset, reset-dms, no, QMI_SERVICE_DMS) \
#define dms_helptext \
+ --get-capabilities: List device
capabilities\n \
--get-pin-status: Get PIN verification
status\n \
--verify-pin1 pin: Verify PIN1\n \
--verify-pin2 pin: Verify PIN2\n \
--
1.9.1
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] [PATCH] [package] openvpn: procd_set_param respawn
From 0c442b23127f58cf4c8c0b96ca67c0335ef86da9 Mon Sep 17 00:00:00 2001
From: Lars Gierth la...@systemli.org
Date: Thu, 8 Jan 2015 16:05:10 +0100
Subject: [PATCH] [package] openvpn: procd_set_param respawn
Makes sure that the openvpn instance gets restarted in case of a crash.
Intentional stops using /etc/init.d/openvpn stop will not result in
respawning. Anything else will, e.g. killall openvpn.
Signed-off-by: Lars Gierth la...@systemli.org
---
package/network/services/openvpn/files/openvpn.init | 1 +
1 file changed, 1 insertion(+)
diff --git a/package/network/services/openvpn/files/openvpn.init
b/package/network/services/openvpn/files/openvpn.init
index 9822f1e..1e0f384 100644
--- a/package/network/services/openvpn/files/openvpn.init
+++ b/package/network/services/openvpn/files/openvpn.init
@@ -62,6 +62,7 @@ openvpn_add_instance() {
--cd $dir \
--config $conf
procd_set_param file $dir/$conf
+ procd_set_param respawn
procd_close_instance
}
--
2.1.0
0x7E86809F.asc
Description: application/pgp-keys
signature.asc
Description: OpenPGP digital signature
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH uqmi] Add command for listing device capabilities
On 2015-01-08 14:55, Sławomir Demeszko wrote:
Signed-off-by: Sławomir Demeszko s.demes...@wireless-instruments.com
---
commands-dms.c | 53 +
commands-dms.h | 2 ++
2 files changed, 55 insertions(+)
diff --git a/commands-dms.c b/commands-dms.c
index a677052..fcb4b93 100644
--- a/commands-dms.c
+++ b/commands-dms.c
@@ -7,6 +7,59 @@ static struct {
char* puk;
} dms_req_data;
+static void cmd_dms_get_capabilities_cb(struct qmi_dev *qmi, struct
qmi_request *req, struct qmi_msg *msg)
+{
+ void *t, *networks;
+ int i;
+ struct qmi_dms_get_capabilities_response res;
+ const char *radio_cap[] = {
+ [QMI_DMS_RADIO_INTERFACE_CDMA20001X] = cdma1x,
+ [QMI_DMS_RADIO_INTERFACE_EVDO] = cdma1xevdo,
+ [QMI_DMS_RADIO_INTERFACE_GSM] = gsm,
+ [QMI_DMS_RADIO_INTERFACE_UMTS] = umts,
+ [QMI_DMS_RADIO_INTERFACE_LTE] = lte,
+ };
+ const char *service_cap[] = {
+ [QMI_DMS_DATA_SERVICE_CAPABILITY_NONE] = none,
+ [QMI_DMS_DATA_SERVICE_CAPABILITY_CS] = cs,
+ [QMI_DMS_DATA_SERVICE_CAPABILITY_PS] = ps,
+ [QMI_DMS_DATA_SERVICE_CAPABILITY_SIMULTANEOUS_CS_PS] =
simultaneous_cs_ps,
+ [QMI_DMS_DATA_SERVICE_CAPABILITY_NON_SIMULTANEOUS_CS_PS] =
non_simultaneous_cs_ps,
+ };
+
+ qmi_parse_dms_get_capabilities_response(msg, res);
+
+ t = blobmsg_open_table(status, NULL);
+
+ blobmsg_add_u32(status, max_tx_channel_rate, (int32_t)
res.data.info.max_tx_channel_rate);
+ blobmsg_add_u32(status, max_rx_channel_rate, (int32_t)
res.data.info.max_rx_channel_rate);
+ if (res.data.info.data_service_capability = 0
res.data.info.data_service_capability ARRAY_SIZE(service_cap))
+ blobmsg_add_string(status, data_service,
service_cap[res.data.info.data_service_capability]);
This causes the following warning on my system:
In file included from /Users/nbd/uqmi/commands.c:139:
/Users/nbd/uqmi/commands-dms.c:36:44: error: comparison of unsigned enum
expression = 0 is always true [-Werror,-Wtautological-compare]
if (res.data.info.data_service_capability = 0
res.data.info.data_service_capability ARRAY_SIZE(service_cap))
~ ^ ~
/Users/nbd/uqmi/commands-dms.c:46:45: error: comparison of unsigned enum
expression = 0 is always true [-Werror,-Wtautological-compare]
if (res.data.info.radio_interface_list[i] = 0
res.data.info.radio_interface_list[i] ARRAY_SIZE(radio_cap))
~ ^ ~
- Felix
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH uqmi] Add missing option for getting tdma signal strength
On 2015-01-08 15:15, Sławomir Demeszko wrote: Signed-off-by: Sławomir Demeszko s.demes...@wireless-instruments.com Applied, thanks. - Felix ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] netifd + split dns servers
Currently a protocol can register a dns server with netifd using the proto_add_dns_server function. That however, does not allow registering a DNS server for a specific domain. I checked the netifd code and there is no provision for that. Would it make sense to add such functionality to netifd, or should I make openconnect directly register its split-dns servers with dnsmasq? regards, Nikos ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] WRT1900AC - Available firmwares ?
Hi all, Does anyone here have a Linksys WRT1900AC (that fiasco that suppose to be the new generation of WRT54G) ? I got one a while ago and have been following the firmware development for it directly with Belkin people and on the URL - https://github.com/wrt1900ac/opensource/tree/master/Barrier-Breaker but that showed to be a total failure as they completely abandoned the project (GitHub latest update is 6 months old and they don' reply to emails anymore). Many here might have seen all discussions around the subject during the initial phase of development especially regarding the open-source firmware of their wireless driver, which so far (as far as I know) is/was still a binary. I have been however looking into the OpenWRT Snapshot and can see the mvebu folder with similar files than Linksys GitHub - http://downloads.openwrt.org/snapshots/trunk/mvebu/ Plus with the information on the wiki - http://wiki.openwrt.org/toh/linksys/wrt1900ac that the wireless driver has been finally released and the issue 'seems' to be resolved I guess. Can anyone confirm this one downloaded from OpenWRT works for WRT1900AC compared to any of the 3 mentioned on the wiki ? Thanks Regards, Fernando ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] [PATCH] igmpproxy: add patch to silence unnecessary logging of downstream igmp traffic
This patch adds a simple check to silence logging of messages about
unrecognized igmp packets which originate from devices in local network.
Without this patch igmpproxy floods openwrt syslog with messages such as:
user.warn igmpproxy[19818]: The source address 192.168.1.175 for group
239.255.250.250, is not in any valid net for upstream VIF.
Signed-off-by: Antti Seppälä a.sepp...@gmail.com
---
...0-Silence-downstream-interface-igmp-messages.patch | 19 +++
1 file changed, 19 insertions(+)
create mode 100644
package/network/services/igmpproxy/patches/020-Silence-downstream-interface-igmp-messages.patch
diff --git
a/package/network/services/igmpproxy/patches/020-Silence-downstream-interface-igmp-messages.patch
b/package/network/services/igmpproxy/patches/020-Silence-downstream-interface-igmp-messages.patch
new file mode 100644
index 000..ccd000c
--- /dev/null
+++
b/package/network/services/igmpproxy/patches/020-Silence-downstream-interface-igmp-messages.patch
@@ -0,0 +1,19 @@
+--- a/src/igmp.c
b/src/igmp.c
+@@ -139,8 +139,14 @@
+ return;
+ }
+ else if(!isAdressValidForIf(checkVIF, src)) {
+-my_log(LOG_WARNING, 0, The source address %s for group %s,
is not in any valid net for upstream VIF.,
+-inetFmt(src, s1), inetFmt(dst, s2));
++struct IfDesc *downVIF = getIfByAddress(src);
++if (downVIF downVIF-state IF_STATE_DOWNSTREAM) {
++my_log(LOG_NOTICE, 0, The source address %s for group %s
is from downstream VIF. Ignoring.,
++inetFmt(src, s1), inetFmt(dst, s2));
++} else {
++my_log(LOG_WARNING, 0, The source address %s for group
%s, is not in any valid net for upstream VIF.,
++inetFmt(src, s1), inetFmt(dst, s2));
++}
+ return;
+ }
+
--
2.0.5
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] WRT1900AC - Available firmwares ?
Hi, On Thu, 08 Jan 2015 17:36:40 +0100, Fernando Frediani fhfredi...@gmail.com wrote: Hi all, Does anyone here have a Linksys WRT1900AC (that fiasco that suppose to be the new generation of WRT54G) ? I got one a while ago and have been following the firmware development for it directly with Belkin people and on the URL - https://github.com/wrt1900ac/opensource/tree/master/Barrier-Breaker but that showed to be a total failure as they completely abandoned the project (GitHub latest update is 6 months old and they don' reply to emails anymore). Many here might have seen all discussions around the subject during the initial phase of development especially regarding the open-source firmware of their wireless driver, which so far (as far as I know) is/was still a binary. OpenWrt support the Mamba for over 7 months now, but we didn't have a wireless driver. Marvell released an open source driver for that chipset to this list just before Christmas. I have been however looking into the OpenWRT Snapshot and can see the mvebu folder with similar files than Linksys GitHub - http://downloads.openwrt.org/snapshots/trunk/mvebu/ Plus with the information on the wiki - http://wiki.openwrt.org/toh/linksys/wrt1900ac that the wireless driver has been finally released and the issue 'seems' to be resolved I guess. Can anyone confirm this one downloaded from OpenWRT works for WRT1900AC compared to any of the 3 mentioned on the wiki ? Anyone can edit the wiki so don't take anything there written in stone. Trunk works on it, but with any new driver, you can run into issues. Imre ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] procd/inittab with a delayed console
Hi,
I'm not sure if this is a bug with procd's implementation of inittab or
if I'm just doing something wrong in my inittab. However, we have a
board that has multiple serial console ports, one of which relies on a
kernel module and procd refuses to start a console on the second port.
What seems to be happening is that procd loads inittab before the kernel
modules are loaded, therefore the tty device doesn't exist yet and the
check for dev_exist() fails and procd never forks a worker for that console.
I was able to fix it for my board with the following patch, but I'm not
sure if this is would be the entire fix for the problem since it seems
like fork_worker() should be a little more graceful in handling tty
devices that don't exist yet.
Any thoughts or suggestions on better ways to fix this?
Thanks,
Owen
diff --git a/inittab.c b/inittab.c
index 2efbf4d..7b12e10 100644
--- a/inittab.c
+++ b/inittab.c
@@ -161,7 +161,7 @@ static void askfirst(struct init_action *a)
{
int i;
- if (!dev_exist(a-id) || (console !strcmp(console, a-id))) {
+ if (console !strcmp(console, a-id)) {
DEBUG(4, Skipping %s\n, a-id);
return;
}
--
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH 1/3] [Lantiq] [P2812HNUFX] Remove old dts
On 27/12/2014 11:32, Sylwester Petela wrote:
Remove unused P2812HNUFX board definition.
Signed-off-by: Sylwester Petela ssc...@gmail.com
---
please change the patch to
* make use of 1 dtsi file and 2 dts files
* after applying your patch 1/3 the tree will not build. please remove
old file at the end of the series
--- a/target/linux/lantiq/dts/P2812HNUFX.dts
+++ /dev/null
@@ -1,308 +0,0 @@
-/dts-v1/;
-
-/include/ vr9.dtsi
-
-/ {
- model = P2812HNUFX - ZyXEL P-2812HNU-Fx;
-
- chosen {
- /*bootargs = console=ttyLTQ0,115200 init=/etc/preinit;*/
- };
-
- memory@0 {
- reg = 0x0 0x800;
- };
-
- fpi@1000 {
- #address-cells = 1;
- #size-cells = 1;
- compatible = lantiq,fpi, simple-bus;
- ranges = 0x0 0x1000 0xEEF;
- reg = 0x1000 0xEF0;
-
- localbus@0 {
- #address-cells = 2;
- #size-cells = 1;
- compatible = lantiq,localbus, simple-bus;
-
- nand-parts@0 {
- compatible = gen_nand, lantiq,nand-xway;
- lantiq,cs = 1;
- bank-width = 2;
- reg = 0 0x0 0x200;
- #address-cells = 1;
- #size-cells = 1;
-
- partition@0 {
- label = u-boot;
- reg = 0x0 0x4;
- };
-
- partition@4 {
- label = u-boot environment;
- reg = 0x4 0x2;
- };
-
- partition@6 {
- label = root;
- reg = 0x6 0x7fa;
- };
- };
- };
-
- gpio: pinmux@E100B10 {
- compatible = lantiq,pinctrl-xr9;
- pinctrl-names = default;
- pinctrl-0 = state_default;
-
- interrupt-parent = icu0;
- interrupts = 166 135 66 40 41 42 38;
-
- #gpio-cells = 2;
- gpio-controller;
- reg = 0xE100B10 0xA0;
-
- state_default: pinmux {
- mdio {
- lantiq,groups = mdio;
- lantiq,function = mdio;
- };
- gphy-leds {
- lantiq,groups = gphy0 led1, gphy1
led1,
- gphy0 led2, gphy1
led2;
- lantiq,function = gphy;
- lantiq,pull = 2;
- lantiq,open-drain = 0;
- lantiq,output = 1;
- };
- stp {
- lantiq,groups = stp;
- lantiq,function = stp;
- lantiq,pull = 2;
- lantiq,open-drain = 0;
- lantiq,output = 1;
- };
- pci {
- lantiq,groups = gnt1, req1;
- lantiq,function = pci;
- };
- pci-rst {
- lantiq,pins = io21;
- lantiq,pull = 0;
- lantiq,open-drain = 0;
- lantiq,output = 1;
- };
- ifxhcd-rst {
- lantiq,pins = io33;
- lantiq,pull = 0;
- lantiq,open-drain = 0;
- lantiq,output = 1;
- };
- nand {
- lantiq,groups = nand cle, nand ale,
- nand rd, nand cs1,
nand rdy;
- lantiq,function = ebu;
- lantiq,pull = 1;
- };
- };
- };
-
- eth@E108000 {
- #address-cells = 1;
- #size-cells = 0;
-
Re: [OpenWrt-Devel] WRT1900AC - Available firmwares ?
On Thu, 08 Jan 2015 20:10:28 +0100, Fernando Frediani fhfredi...@gmail.com wrote: I have just upgraded it with your firmware. Works fine so far for most of things. Actually some stuff is better than before. Glad to hear that :) I will proceed with more tests, specially the ones I had been doing and reported back to Belkin a while ago to make sure they are gone. Is there any GitHub or anywhere to report the findings to ? If it's related to core stuff, the OpenWrt bug tracker is the way to go, if the wifi driver, creating a ticket on github.com/kaloz/mwlwifi is what you're looking for. Imre ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH] Comgt: Add option to ignore ioctl errors
On 29/12/2014 17:54, Matti Laakso wrote:
Some Huawei mobile broadband sticks utilizing the NCM protocol expose
the control channel as a cdc-wdm device node instead of a virtual serial
port. This device node does not support the serial port ioctls. Add command
line option to not check whether ioctls are successful so that AT commands
can also be sent to these devices.
can you instead of calling the ioctl and then ignoring the error change
it to not call the ioctls if the device is not a tty ?
Signed-off-by: Matti Laakso malaa...@elisanet.fi
---
.../utils/comgt/patches/004-add_force_option.patch | 66
++
1 file changed, 66 insertions(+)
create mode 100644
package/network/utils/comgt/patches/004-add_force_option.patch
diff --git a/package/network/utils/comgt/patches/004-add_force_option.patch
b/package/network/utils/comgt/patches/004-add_force_option.patch
new file mode 100644
index 000..1690e5c
--- /dev/null
+++ b/package/network/utils/comgt/patches/004-add_force_option.patch
@@ -0,0 +1,66 @@
+--- a/comgt.c
b/comgt.c
+@@ -91,6 +91,7 @@ unsigned long hstart,hset;
+ char NullString[]={ };
+ BOOL lastcharnl=1; /* Indicate that last char printed from getonebyte
+was a nl, so no new one is needed */
++BOOL force=0;
+
+
+ //open com \/dev/modem\\nset com 38400n81\nset senddelay 0.05\nsend
\ATi^m\\nget 2 \ ^m\ $s\nprint \Response : \,$s,\\\n\\nget 2 \ ^m\
$s\nprint \Response :\,$s,\\\n\\nget 2 \ ^m\ $s\nprint \Response :
\,$s,\\\n\\n\n;
+@@ -920,7 +921,7 @@ BOOL getonoroff(void) {
+ void setcom(void) {
+ stbuf.c_cflag = ~(CBAUD | CSIZE | CSTOPB | CLOCAL | PARENB);
+ stbuf.c_cflag |= (speed | bits | CREAD | clocal | parity | stopbits );
+- if (ioctl(comfd, TCSETA, stbuf) 0) {
++ if (ioctl(comfd, TCSETA, stbuf) 0 !force) {
+ serror(Can't ioctl set device,1);
+ }
+ }
+@@ -1224,7 +1225,7 @@ void doclose(void) {
+ if(strcmp(token,hardcom)==0) {
+ if(comfd== -1) serror(Com device not open,1);
+ vmsg(Closing device);
+-if (ioctl(comfd, TCSETA, svbuf) 0) {
++if (ioctl(comfd, TCSETA, svbuf) 0 !force) {
+ sprintf(msg,Can't ioctl set device %s.\n,device);
+ serror(msg,1);
+ }
+@@ -1266,7 +1267,7 @@ void opengt(void) {
+ ext(1);
+ }
+ }
+- if (ioctl (comfd, TCGETA, svbuf) 0) {
++ if (ioctl (comfd, TCGETA, svbuf) 0 !force) {
+ sprintf(msg,Can't control %s, please try again.\n,device);
+ serror(msg,1);
+ }
+@@ -1303,7 +1304,7 @@ void opendevice(void) {
+ }
+ else comfd=0;
+
+- if (ioctl (comfd, TCGETA, svbuf) 0) {
++ if (ioctl (comfd, TCGETA, svbuf) 0 !force) {
+ sprintf(msg,Can't ioctl get device %s.\n,device);
+ serror(msg,1);
+ }
+@@ -1567,7 +1568,7 @@ int main(int argc,char **argv) {
+ for(a=0;astrlen(argv[0]);a++) {
+ if(argv[0][a]=='/') b=a+1;
+ }
+- while((aa=getopt(argc,argv,xheVvd:t:sb:))!= -1) {
++ while((aa=getopt(argc,argv,xheVvd:t:sb:f))!= -1) {
+ switch(aa) {
+ case 0:
+ ext(0);
+@@ -1605,6 +1606,10 @@ int main(int argc,char **argv) {
+ printf(High speed overide (115200 is now 57600).\n);
+ high_speed =1;
+ break;
++ case 'f':
++force=1;
++vmsg(Ignoring ioctl errors);
++break;
+ default:
+ ext(1);
+ }
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
