Re: [OpenWrt-Devel] How to recognize if a default route is active
Hi, please do not do dirty hacks like relying on an interface called wan in your scripts. You should develop a hotplug handler which is invoked for ifup events on any interface. As soon as one interface appears which carries as 0/0 route, you have your wan. See the 6in4 and 6to4 packages for inspiration. ~ Jow ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] How to recognize if a default route is active
I'd suggest to use ip route list exact 0.0.0.0/0 to find the device and then the find_config() shell function to map the device to an uci interface name. ~ Jow ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] How to recognize if a default route is active
I have however a designed issue. At the moment a bash daemon periodically checks if the wan interface is up. If the check is positive then the mesh daemon advertise this gateway, otherwise the mesh interface is set as default route. in the OLSR routing protocol implementation, we have a dynamic gateway plugin. It checks (with policy routing) if connectivity with the Internet is actually working, before the router advertises a default route. you might want to check out the code on olsr.org Saverio ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] [PATCH v3 0/2] 802.1Q VLAN support for ADM6996M/ADM6996FC
These patches add support for 802.1Q VLANs on ADM6996M and ADM6996FC. It is called version 3; version 2 wasn't explicitly called as such, but the version I sent April 3 would be it. I am submitting for inclusion in OpenWRT the driver for the M chip. Since I don't have the FC chip, I cannot test if it all works as you would expect and hope for that chip. I still include a patch enabling its support, but not for inclusion in OpenWRT just now. If other people feel they have sufficiently tested that the driver works, they are free to submit it for inclusion themselves. I will try to offer support, but it's somewhat limited without hardware :). Since a lot more people seem to have FC chips than M chips, the driver I'm not actually submitting for inclusion seems to be the most interesting. So be it. It still exists. If it works well, it can then be included. Many, many thanks for all comments and help on this driver. I have learned a lot about PHYs in Linux :). Peter. -- I use the GNU Privacy Guard (GnuPG) in combination with Enigmail. You can send me encrypted mail if you want some privacy. My key is available at http://wwwhome.cs.utwente.nl/~lebbing/pubkey.txt ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] [PATCH v3 1/2] 802.1Q VLAN support for ADM6996M/ADM6996FC
This patch adds 802.1Q VLAN support for the ADM6996M chip. The driver is loaded for both the FC and M model. It will detect which of the two chips is connected. The FC model is initialised, but no further functionality is offered. The PHY driver will always report 100 Mbit/s, link up, for both the M and FC models. This reflects the fact that the link between switch chip and Ethernet MAC is always on[1]. Further documentation can be found in the kernel's Documentation/networking/adm6996.txt Changes compared to the original driver: - Don't mask the Version Number (least significant nibble from Chip Identifier 0, register 0xA0) from the matching code. Since I already had trouble telling the FC and M chips apart, both Version Number 3, I included this field in the match again. - Don't handle port 0 as a WAN port because in my opinion it just makes stuff more complicated to understand and explain. At least on the D-Link DSL-G624T and the Ubiquiti RouterStation, it's just a LAN port anyway. - Don't reset port 4. I changed ADM_PHY_PORTS so only ports 0 through 3 are reset. Port 4 is a special port, the datasheet says its most popular use is as a WAN port :), connected to a second MAC. It can also be used as a regular port. But for instance the Ubiquiti RouterStation indeed uses it connected to a second MAC, and the Generic PHY driver on address 20 decimal fits this purpose well. In that case, it should be the Generic PHY driver handling and thus resetting that port, and the ADM6996 driver should just leave it alone. - Match ONLY on PHY addresses 0-10 inclusive instead of all addresses. The ADM6996 has custom registers in that range, so matching there somewhat prevents register corruption by other drivers (specifically the Generic PHY driver). The driver will only offer VLAN functionality when bound as address 0. Note that the ADM6996 exports standard PHY registers (Generic PHY compatible) on addresses 16 through 20 for ports 0 through 4. Especially address 20 is useful. Ports 0 through 3 are always switch ports and never directly connected to the MII bus of a MAC. - The allocation and initialisation of the adm6996_priv structure is now in config_init() instead of probe(). It is only done for PHY address 0, where it is useful. Also, register_switch() is an additional failure point where the structure should be freed. - Added myself to MODULE_AUTHOR [1] The switch chip can set the link state to down using a custom register bit. I suppose this is for power-saving, but it is not implemented in the driver. Signed-off-by: Peter Lebbing pe...@digitalbrains.com --- Compared to version 2 of April 3 (which wasn't explicitly called version 2), the changes are: - Detect and tell apart M and FC chip. Thanks everybody! - Handling of PHY addresses as explained above - Added Documentation/networking/adm6996.txt - Don't set PVID of port 0 to ID 1 (handle port 0 as WAN port from above) - Use ADM6996_PHY_PORTS as the number of PHYs of the switch chip to handle instead of the total number of ports (I suppose I initially misunderstood its use, this seems to make more sense) - Additionally define ADM6996_NUM_PORTS to mean the total number of ports - Fixed bug where an apply invocation with enable_vlan = 0 and vlan_enabled = 0 would still set VLAN filters. - Implement reset; the ADM6996 chip doesn't seem to offer a software-initiated reset, see adm6996.txt. - Invoke unregister_switch() in adm6996_remove files/Documentation/networking/adm6996.txt | 110 + files/drivers/net/phy/adm6996.c| 616 +++-- files/drivers/net/phy/adm6996.h| 67 ++- patches-2.6.30/620-phy_adm6996.patch |6 patches-2.6.31/620-phy_adm6996.patch |6 patches-2.6.32/620-phy_adm6996.patch |6 patches-2.6.35/620-phy_adm6996.patch |6 patches-2.6.36/620-phy_adm6996.patch |6 patches-2.6.37/620-phy_adm6996.patch |6 patches-2.6.38/620-phy_adm6996.patch |6 patches-2.6.39/620-phy_adm6996.patch |6 11 files changed, 795 insertions(+), 46 deletions(-) Index: target/linux/generic/patches-2.6.35/620-phy_adm6996.patch === --- target/linux/generic/patches-2.6.35/620-phy_adm6996.patch (revision 26657) +++ target/linux/generic/patches-2.6.35/620-phy_adm6996.patch (working copy) @@ -1,13 +1,15 @@ --- a/drivers/net/phy/Kconfig +++ b/drivers/net/phy/Kconfig -@@ -93,6 +93,11 @@ config MICREL_PHY +@@ -93,6 +93,13 @@ config MICREL_PHY ---help--- Supports the KSZ9021, VSC8201, KS8001 PHYs. +config ADM6996_PHY + tristate Driver for ADM6996 switches ++ select SWCONFIG + ---help--- -+Currently supports the ADM6996F switch ++Currently supports the ADM6996FC and ADM6996M switches. ++Support for FC is very limited. + config FIXED_PHY bool Driver for MDIO Bus/PHY emulation with fixed speed/link
[OpenWrt-Devel] [PATCH v3 2/2] 802.1Q VLAN support for ADM6996M/ADM6996FC
This patch, when applied on top of [PATCH v3 1/2], will enable VLAN support for the ADM6996FC. It updates the whole to be identical to the patch I sent in on April 12, though that patch also includes a board fix for the Ubiquiti RouterStation PHY masks that is not here. And it was against backfire instead of trunk. /Please do not include this in OpenWRT just yet/ I cannot test the functionality on the FC chip myself. Yeoh Chun Yeow reported it works. He figured out the register bit to set so untagged and tagged memberships both work, albeit not simultaneously on the same switch port. Things that I think should be tested are, for example: - Do all combinations of VLAN table entry and VLAN ID work? I.e., does the vid property of a VLAN entry work and can it be set to anything in the range 0 through 1023 without limitations. Obviously I'm not advocating trying out all sixteen thousand possible combinations :). - Handling of VLAN ID 0, 1 and 1023. These have the possibility to be handled specially on these chips. More in general, VLAN ID 0 is often a default one and Linux even warns you about using VLAN ID 1. I'm not sure about the status of VID 1023, but it might be considered invalid by some or a lot of devices. So it makes sense to scrutinise these three IDs further to see that they don't do unexpected, unwanted stuff. The M chip handles VID 0, 1 and 1023 like any other. AFAIK obviously. - Unexpected VIDs. What happens when a tagged packet comes in for a VLAN ID not configured in the switch? What happens when a tagged packet comes in with a VLAN ID that is in use on the switch, but the incoming port is not member of that VLAN? What happens when an untagged packet comes in and the Primary VLAN ID is set to an unconfigured VLAN or a VLAN of which the port is not a member? In all these cases, the M chip drops the packet (source port filtering). - How is the 802.1p priority field handled? The M chip will pass through the priority field of the incoming packet. If the incoming packet was untagged, the priority is set to 0. - Enabling and disabling VLAN support: its effect on switch behaviour. The two bugs in my original code where related to disabling the VLAN (enable_vlan set to 0). At least I fell in the pit of testing all functionality, and not testing the absence of functionality, in a way. The second bug, where VLAN filters were being set even though enable_vlan = 0, had the potential of corrupting non-VLAN switching behaviour through 'swconfig set vlan X ports' statements that should have no effect with enable_vlan = 0 but did have an effect. I haven't tested it, but I'm fairly sure they would have changed the switch's behaviour. --- files/Documentation/networking/adm6996.txt | 20 +- files/drivers/net/phy/adm6996.c| 87 - patches-2.6.30/620-phy_adm6996.patch |3 - patches-2.6.31/620-phy_adm6996.patch |3 - patches-2.6.32/620-phy_adm6996.patch |3 - patches-2.6.35/620-phy_adm6996.patch |3 - patches-2.6.36/620-phy_adm6996.patch |3 - patches-2.6.37/620-phy_adm6996.patch |3 - patches-2.6.38/620-phy_adm6996.patch |3 - patches-2.6.39/620-phy_adm6996.patch |3 - --- target/linux/generic/patches-2.6.35/620-phy_adm6996.patch (working copy) +++ target/linux/generic/patches-2.6.35/620-phy_adm6996.patch (working copy) @@ -1,6 +1,6 @@ --- a/drivers/net/phy/Kconfig +++ b/drivers/net/phy/Kconfig -@@ -93,6 +93,13 @@ config MICREL_PHY +@@ -93,6 +93,12 @@ config MICREL_PHY ---help--- Supports the KSZ9021, VSC8201, KS8001 PHYs. @@ -9,7 +9,6 @@ + select SWCONFIG + ---help--- +Currently supports the ADM6996FC and ADM6996M switches. -+Support for FC is very limited. + config FIXED_PHY bool Driver for MDIO Bus/PHY emulation with fixed speed/link PHYs --- target/linux/generic/patches-2.6.36/620-phy_adm6996.patch (working copy) +++ target/linux/generic/patches-2.6.36/620-phy_adm6996.patch (working copy) @@ -1,6 +1,6 @@ --- a/drivers/net/phy/Kconfig +++ b/drivers/net/phy/Kconfig -@@ -93,6 +93,13 @@ config MICREL_PHY +@@ -93,6 +93,12 @@ config MICREL_PHY ---help--- Supports the KSZ9021, VSC8201, KS8001 PHYs. @@ -9,7 +9,6 @@ + select SWCONFIG + ---help--- +Currently supports the ADM6996FC and ADM6996M switches. -+Support for FC is very limited. + config FIXED_PHY bool Driver for MDIO Bus/PHY emulation with fixed speed/link PHYs --- target/linux/generic/patches-2.6.37/620-phy_adm6996.patch (working copy) +++ target/linux/generic/patches-2.6.37/620-phy_adm6996.patch (working copy) @@ -1,6 +1,6 @@ --- a/drivers/net/phy/Kconfig +++ b/drivers/net/phy/Kconfig -@@ -92,6 +92,13 @@ config MICREL_PHY +@@ -92,6 +92,12 @@ config MICREL_PHY ---help--- Supports the KSZ9021, VSC8201, KS8001 PHYs. @@ -9,7 +9,6 @@ + select SWCONFIG +
Re: [OpenWrt-Devel] Shouldn't CONFIG_ATH_USER_REGD=y by default?
I think the current situation of enforcing ETSI limits on US machines flies in the face of WIRELESS FREEDOM. In the interest of collaboration Atheros specifically wants OpenWrt to not publish unregulated binaries. One prerequisite for publishing a fully open driver was the ability to enforce effective limits on spectrum usage - so essentially the enforcement is what allowed actual Wireless Freedom in the first place. We are much less densely populated in rural America and need to operate at FCC authorized power levels in order to reach many of our subscribers. Work is being done to properly fix the regulation code but that is another matter than allowing user overrides. ~ Jow ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] Shouldn't CONFIG_ATH_USER_REGD=y by default?
On Thu, Apr 14, 2011 at 10:25 AM, Jo-Philipp Wich x...@subsignal.org wrote: I think the current situation of enforcing ETSI limits on US machines flies in the face of WIRELESS FREEDOM. In the interest of collaboration Atheros specifically wants OpenWrt to not publish unregulated binaries. One prerequisite for publishing a fully open driver was the ability to enforce effective limits on spectrum usage - so essentially the enforcement is what allowed actual Wireless Freedom in the first place. We are much less densely populated in rural America and need to operate at FCC authorized power levels in order to reach many of our subscribers. Work is being done to properly fix the regulation code but that is another matter than allowing user overrides. ~ Jow Good morning, Jo-Philipp. Please see ticket https://dev.openwrt.org/ticket/9207. We are not asking to override anything if I understand the matter correctly. We are asking that OpenWrt allow legal power limits for use where it is necessary. At the moment, IMHO, it does not, but like Dennis Miller at the end of a rant, I could be wrong about that. respectfully submitted/ldv -- Larry Vaden, CoFounder Internet Texoma, Inc. Serving Rural Texomaland Since 1995 We Care About Your Connection! ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] Shouldn't CONFIG_ATH_USER_REGD=y by default?
On 2011-04-14 5:41 PM, Larry Vaden wrote: On Thu, Apr 14, 2011 at 10:25 AM, Jo-Philipp Wichx...@subsignal.org wrote: I think the current situation of enforcing ETSI limits on US machines flies in the face of WIRELESS FREEDOM. In the interest of collaboration Atheros specifically wants OpenWrt to not publish unregulated binaries. One prerequisite for publishing a fully open driver was the ability to enforce effective limits on spectrum usage - so essentially the enforcement is what allowed actual Wireless Freedom in the first place. We are much less densely populated in rural America and need to operate at FCC authorized power levels in order to reach many of our subscribers. Work is being done to properly fix the regulation code but that is another matter than allowing user overrides. ~ Jow Good morning, Jo-Philipp. Please see tickethttps://dev.openwrt.org/ticket/9207. We are not asking to override anything if I understand the matter correctly. We are asking that OpenWrt allow legal power limits for use where it is necessary. I've reproduced the bug that you described and poked the guy responsible for the buggy code. If he posts a fix, I'll merge it and backport it. Meanwhile I'm already working out the design for a rewrite of the cfg80211 regulatory code, because I think the original code is too messed up to be sustainable in the long run. - Felix ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] Shouldn't CONFIG_ATH_USER_REGD=y by default?
On Thu, Apr 14, 2011 at 10:47 AM, Felix Fietkau n...@openwrt.org wrote: On 2011-04-14 5:41 PM, Larry Vaden wrote: On Thu, Apr 14, 2011 at 10:25 AM, Jo-Philipp Wichx...@subsignal.org wrote: I think the current situation of enforcing ETSI limits on US machines flies in the face of WIRELESS FREEDOM. In the interest of collaboration Atheros specifically wants OpenWrt to not publish unregulated binaries. One prerequisite for publishing a fully open driver was the ability to enforce effective limits on spectrum usage - so essentially the enforcement is what allowed actual Wireless Freedom in the first place. We are much less densely populated in rural America and need to operate at FCC authorized power levels in order to reach many of our subscribers. Work is being done to properly fix the regulation code but that is another matter than allowing user overrides. ~ Jow Good morning, Jo-Philipp. Please see tickethttps://dev.openwrt.org/ticket/9207. We are not asking to override anything if I understand the matter correctly. We are asking that OpenWrt allow legal power limits for use where it is necessary. I've reproduced the bug that you described and poked the guy responsible for the buggy code. If he posts a fix, I'll merge it and backport it. Meanwhile I'm already working out the design for a rewrite of the cfg80211 regulatory code, because I think the original code is too messed up to be sustainable in the long run. - Felix Felix, your word that you will take care of the matter is more than satisfactory. One more question, please, before closing the thread: For purposes of planning the direly needed migration from AirOS to OpenWrt, do you have a guestimate of when we'll be happy as a dead pig in the sunshine? respectfully submitted/ldv -- Larry Vaden, CoFounder Internet Texoma, Inc. Serving Rural Texomaland Since 1995 We Care About Your Connection! ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] Shouldn't CONFIG_ATH_USER_REGD=y by default?
On 2011-04-14 5:59 PM, Larry Vaden wrote: On Thu, Apr 14, 2011 at 10:47 AM, Felix Fietkaun...@openwrt.org wrote: On 2011-04-14 5:41 PM, Larry Vaden wrote: On Thu, Apr 14, 2011 at 10:25 AM, Jo-Philipp Wichx...@subsignal.org wrote: I think the current situation of enforcing ETSI limits on US machines flies in the face of WIRELESS FREEDOM. In the interest of collaboration Atheros specifically wants OpenWrt to not publish unregulated binaries. One prerequisite for publishing a fully open driver was the ability to enforce effective limits on spectrum usage - so essentially the enforcement is what allowed actual Wireless Freedom in the first place. We are much less densely populated in rural America and need to operate at FCC authorized power levels in order to reach many of our subscribers. Work is being done to properly fix the regulation code but that is another matter than allowing user overrides. ~ Jow Good morning, Jo-Philipp. Please see tickethttps://dev.openwrt.org/ticket/9207. We are not asking to override anything if I understand the matter correctly. We are asking that OpenWrt allow legal power limits for use where it is necessary. I've reproduced the bug that you described and poked the guy responsible for the buggy code. If he posts a fix, I'll merge it and backport it. Meanwhile I'm already working out the design for a rewrite of the cfg80211 regulatory code, because I think the original code is too messed up to be sustainable in the long run. - Felix Felix, your word that you will take care of the matter is more than satisfactory. One more question, please, before closing the thread: For purposes of planning the direly needed migration from AirOS to OpenWrt, do you have a guestimate of when we'll be happy as a dead pig in the sunshine? No idea. But I'll let you know when it's done. - Felix ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [OpenWrt-Commits] r26654 - packages/utils/hdparm
On Wed, Apr 13, 2011 at 04:38:16PM -0600, Philip Prindeville wrote: I actually think the older description was a lot more informative. I agree. But I thought that description supposed to be like on the tools home page. I mean you should not learn how to use a tool from OpenWrt description. Or am I wrong? The -f, -t, -T, and -z flags don't get or set parameters, for example... and these are amongst the handiest arguments to the command. On 4/13/11 4:20 PM, openwrt-comm...@openwrt.org wrote: Author: luka Date: 2011-04-14 00:20:46 +0200 (Thu, 14 Apr 2011) New Revision: 26654 Modified: packages/utils/hdparm/Makefile Log: upgrade hdparm Modified: packages/utils/hdparm/Makefile === --- packages/utils/hdparm/Makefile 2011-04-13 22:14:18 UTC (rev 26653) +++ packages/utils/hdparm/Makefile 2011-04-13 22:20:46 UTC (rev 26654) @@ -1,5 +1,5 @@ # -# Copyright (C) 2006-2008 OpenWrt.org +# Copyright (C) 2006-2011 OpenWrt.org # # This is free software, licensed under the GNU General Public License v2. # See /LICENSE for more information. @@ -8,12 +8,12 @@ include $(TOPDIR)/rules.mk PKG_NAME:=hdparm -PKG_VERSION:=9.27 +PKG_VERSION:=9.37 PKG_RELEASE:=1 PKG_SOURCE:=$(PKG_NAME)-$(PKG_VERSION).tar.gz PKG_SOURCE_URL:=@SF/$(PKG_NAME) -PKG_MD5SUM:=e652dabb6c9233fb8a23ef60a17a1829 +PKG_MD5SUM:=0bb94ddd1bedd5c02b1ca62f1caaf6de include $(INCLUDE_DIR)/package.mk @@ -23,18 +23,13 @@ SUBMENU:=disc TITLE:=Hard disk drive configuration utilitity URL:=http://sourceforge.net/projects/hdparm/ + MAINTAINER:=Luka Perkov open...@lukaperkov.net endef define Package/hdparm/description - Tune hard disk parameters for high performance. - Get/set hard disk parameters for Linux IDE drives. - Primary use is for enabling irq-unmasking and IDE multiplemode. + get/set SATA/IDE device parameters endef -MAKE_FLAGS += \ - CFLAGS=$(EXTRA_CFLAGS) \ - LDFLAGS=$(EXTRA_LDFLAGS) \ - define Package/hdparm/install $(INSTALL_DIR) $(1)/sbin $(INSTALL_BIN) $(PKG_BUILD_DIR)/$(PKG_NAME) $(1)/sbin ___ openwrt-commits mailing list openwrt-comm...@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-commits ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] learning moment bitte: what are the advantages of deauthenticating due to inactivity?
I ask because this STA never came back. The STA is running AirOS v3.6, which was forked so long ago that the completion of its bitrot will be announced shortly :) Said STAs are hit once every five minutes by smokeping. jv-2400-ap1/2011-04-14.log:301 2011-04-14T19:25:35+00:00 jv-2400-ap1 hostapd - - - wlan0: STA 00:15:6d:ad:65:83 IEEE 802.11: deauthenticated due to inactivity jv-2400-ap1/2011-04-14.log:301 2011-04-14T19:26:00+00:00 jv-2400-ap1 hostapd - - - wlan0: STA 00:15:6d:ad:65:83 IEEE 802.11: authenticated jv-2400-ap1/2011-04-14.log:301 2011-04-14T19:26:00+00:00 jv-2400-ap1 hostapd - - - wlan0: STA 00:15:6d:ad:65:83 IEEE 802.11: associated (aid 8) jv-2400-ap1/2011-04-14.log:301 2011-04-14T19:28:24+00:00 jv-2400-ap1 hostapd - - - wlan0: STA 00:15:6d:ad:65:83 IEEE 802.11: disassociated jv-2400-ap1/2011-04-14.log:301 2011-04-14T19:28:25+00:00 jv-2400-ap1 hostapd - - - wlan0: STA 00:15:6d:ad:65:83 IEEE 802.11: deauthenticated due to inactivity -- Larry Vaden, CoFounder Internet Texoma, Inc. Serving Rural Texomaland Since 1995 We Care About Your Connection! ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [OpenWrt] #9207: txpower may be limited to 20 dBm on Ubiquiti M900 series with regdomain=US
On Thu, Apr 14, 2011 at 7:08 PM, OpenWrt openwrt-devel@lists.openwrt.org wrote: #9207: txpower may be limited to 20 dBm on Ubiquiti M900 series with regdomain=US ---+ Reporter: vaden@… | Owner: developers Type: defect | Status: closed Priority: high | Milestone: Attitude Adjustment (trunk) Component: base system | Version: Trunk Resolution: fixed | Keywords: txpower Ubiquiti M900 ap cpe ---+ Comment(by nbd): I'm pretty sure the signal strength values match what the hardware thinks the signal strength is, but I'm not sure about the interpretation of those values yet. I'm already looking into that and I don't think opening up a new ticket for that helps. Since Trac is so convinced I'm spamming (Submission rejected as potential spam (SpamBayes determined spam probability of 59.17%)), I'll ask on the ML: Does the radio deal in absolutes (e.g., microvolts) or is everything relative? e.g., does the radio know the noise floor and report said to you or do you tell the radio what the noise floor is? kind regards/ldv ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [OpenWrt] #9207: txpower may be limited to 20 dBm on Ubiquiti M900 series with regdomain=US
On 2011-04-15 2:18 AM, Larry Vaden wrote: On Thu, Apr 14, 2011 at 7:08 PM, OpenWrt openwrt-devel@lists.openwrt.org wrote: #9207: txpower may be limited to 20 dBm on Ubiquiti M900 series with regdomain=US ---+ Reporter: vaden@… | Owner: developers Type: defect| Status: closed Priority: high | Milestone: Attitude Adjustment (trunk) Component: base system | Version: Trunk Resolution: fixed |Keywords: txpower Ubiquiti M900 ap cpe ---+ Comment(by nbd): I'm pretty sure the signal strength values match what the hardware thinks the signal strength is, but I'm not sure about the interpretation of those values yet. I'm already looking into that and I don't think opening up a new ticket for that helps. Since Trac is so convinced I'm spamming (Submission rejected as potential spam (SpamBayes determined spam probability of 59.17%)), I'll ask on the ML: Does the radio deal in absolutes (e.g., microvolts) or is everything relative? e.g., does the radio know the noise floor and report said to you or do you tell the radio what the noise floor is? Radio measures noise floor, driver sanitizes it and sets the final value. Signal strength measurement is based on driver RSSI values. - Felix ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [OpenWrt] #9207: txpower may be limited to 20 dBm on Ubiquiti M900 series with regdomain=US
The AR9280 radio is pretty sensitive. I've seen it register a noise floor below -100dBm in 20mhz-wide 11g channels. I don't know what it'd look like in 900mhz mode. Adrian On 15 April 2011 08:18, Larry Vaden va...@texoma.net wrote: On Thu, Apr 14, 2011 at 7:08 PM, OpenWrt openwrt-devel@lists.openwrt.org wrote: #9207: txpower may be limited to 20 dBm on Ubiquiti M900 series with regdomain=US ---+ Reporter: vaden@… | Owner: developers Type: defect| Status: closed Priority: high | Milestone: Attitude Adjustment (trunk) Component: base system | Version: Trunk Resolution: fixed |Keywords: txpower Ubiquiti M900 ap cpe ---+ Comment(by nbd): I'm pretty sure the signal strength values match what the hardware thinks the signal strength is, but I'm not sure about the interpretation of those values yet. I'm already looking into that and I don't think opening up a new ticket for that helps. Since Trac is so convinced I'm spamming (Submission rejected as potential spam (SpamBayes determined spam probability of 59.17%)), I'll ask on the ML: Does the radio deal in absolutes (e.g., microvolts) or is everything relative? e.g., does the radio know the noise floor and report said to you or do you tell the radio what the noise floor is? kind regards/ldv ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] [PATCH] geos: Add PC speaker to kernel definitions
Add the PC speaker back to the Geos platform. Signed-off-by: Philip Prindeville phil...@redfish-solutions.com --- Index: target/linux/x86/geos/config-default === --- target/linux/x86/geos/config-default(revision 26677) +++ target/linux/x86/geos/config-default(working copy) @@ -13,7 +13,7 @@ CONFIG_MGEODE_LX=y # CONFIG_MOUSE_PS2 is not set # CONFIG_PCIEPORTBUS is not set -# CONFIG_PCSPKR_PLATFORM is not set +CONFIG_PCSPKR_PLATFORM=y CONFIG_PROCESSOR_SELECT=y # CONFIG_SCx200 is not set # CONFIG_SERIO_I8042 is not set ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] [PATCH] geos: uci-defaults updates
Punch firewall holes for ISAKMP (udp port 500) and IPsec ESP. Set system.foreground to 1 to force scripts to complete before starting console shell. Signed-off-by: Philip Prindeville phil...@redfish-solutions.com --- Index: target/linux/x86/geos/base-files/etc/uci-defaults/firewall === --- target/linux/x86/geos/base-files/etc/uci-defaults/firewall (revision 0) +++ target/linux/x86/geos/base-files/etc/uci-defaults/firewall (revision 0) @@ -0,0 +1,33 @@ +#!/bin/sh + +uci batch __EOF__ + +add firewall rule +set firewall.@rule[-1].src=wan +set firewall.@rule[-1].dest_port=123 +set firewall.@rule[-1].target=ACCEPT +set firewall.@rule[-1].proto=udp + +add firewall rule +set firewall.@rule[-1].src=wan +set firewall.@rule[-1].dest=lan +set firewall.@rule[-1].proto=esp +set firewall.@rule[-1].target=ACCEPT + +add firewall rule +set firewall.@rule[-1].src=wan +set firewall.@rule[-1].dest=lan +set firewall.@rule[-1].src_port=500 +set firewall.@rule[-1].dest_port=500 +set firewall.@rule[-1].proto=udp +set firewall.@rule[-1].target=ACCEPT + +add firewall rule +set firewall.@rule[-1].src=wan +set firewall.@rule[-1].dest_port=22 +set firewall.@rule[-1].target=ACCEPT +set firewall.@rule[-1].proto=tcp + +commit firewall +__EOF__ + Index: target/linux/x86/geos/base-files/etc/uci-defaults/foreground === --- target/linux/x86/geos/base-files/etc/uci-defaults/foreground (revision 0) +++ target/linux/x86/geos/base-files/etc/uci-defaults/foreground (revision 0) @@ -0,0 +1,6 @@ +#!/bin/sh + +uci set 'system.@system[0].foreground=1' + +uci commit system + ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH] geos: uci-defaults updates
On Thu, 14 Apr 2011 22:05:27 -0600 Philip Prindeville philipp_s...@redfish-solutions.com wrote: Punch firewall holes for ISAKMP (udp port 500) and IPsec ESP. Set system.foreground to 1 to force scripts to complete before starting console shell. Signed-off-by: Philip Prindeville phil...@redfish-solutions.com --- I don't think making ISAKMP (IPSec) default firewall for only one platform makes sense. Either it makes sense for the firewall in general, or it shouldn't be in a default image IMO. Jo, any comments? Also system.foreground=1 is another thing that should be a debugging optoin, not a general use option. -- erno hm. I've lost a machine.. literally _lost_. it responds to ping, it works completely, I just can't figure out where in my apartment it is. GnuPG Key Fingerprint 86 F5 81 A5 D4 2E 1F 1C http://gnupg.org signature.asc Description: PGP signature ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH] geos: Add PC speaker to kernel definitions
On Thu, 14 Apr 2011 20:31:14 -0600 Philip Prindeville philipp_s...@redfish-solutions.com wrote: Add the PC speaker back to the Geos platform. Signed-off-by: Philip Prindeville phil...@redfish-solutions.com --- Index: target/linux/x86/geos/config-default === --- target/linux/x86/geos/config-default(revision 26677) +++ target/linux/x86/geos/config-default(working copy) @@ -13,7 +13,7 @@ CONFIG_MGEODE_LX=y # CONFIG_MOUSE_PS2 is not set # CONFIG_PCIEPORTBUS is not set -# CONFIG_PCSPKR_PLATFORM is not set +CONFIG_PCSPKR_PLATFORM=y CONFIG_PROCESSOR_SELECT=y # CONFIG_SCx200 is not set # CONFIG_SERIO_I8042 is not set ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel Committed. -- erno hm. I've lost a machine.. literally _lost_. it responds to ping, it works completely, I just can't figure out where in my apartment it is. GnuPG Key Fingerprint 86 F5 81 A5 D4 2E 1F 1C http://gnupg.org signature.asc Description: PGP signature ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
