I've created a hosted wlan network under windows 8 using
netsh wlan set hostednetwork mode=allow ssid=”MySSID” key=”password”
and
netsh wlan show hostednetwork
So far so good, but the channel number is set automatic by netsh. Is there a possibility to change the number manually?
netsh does not support this special configuration. You have to configure channel settings directly on the hardware yourself. In my special case it was possible to set the channel in the device properties of windows. With some older hardware you have to configure the AP through a vendor configuration tool or by modifying the firmware itself in extreme circumstances.
Apparently this is a hardware specific option. For example, on the very common external USB WiFi stick, the Atheros based TP-LINK TL-WN722N (and several others), the channel option is not available on the Advanced properties tab from the Device Manager. Instead, you need to hack the driver INF file for your specific card. To find the driver you use, open an administrative command shell and type:
netsh wlan show all
and then look for the INF file path:
Wireless System Information Summary
(Time: 2015-08-25 11:38:33 FLE Summer Time)
=======================================================================
============================== SHOW DRIVERS ===========================
=======================================================================
Interface name: WiFi 2
Driver : TP-LINK Wireless USB Adapter
Vendor : TP-LINK
Provider : TP-LINK
Date : 2013-11-19
Version : 10.0.0.28
INF file : C:\Windows\INF\oem20.inf
Files : 1 total
C:\Windows\system32\DRIVERS\athuwbx.sys
Type : Native Wi-Fi Driver
Now make a copy of that file and open it in a descent text editor. Look for the [adhocchannelselect.reg] entries. In particular search for the defaultIbssChannel key. In my case it look like this:
HKR, Ndi\params\defaultIbssChannel, ParamDesc, 0, %adhocchannel%
HKR, Ndi\params\defaultIbssChannel, default, 0, "8"
HKR, Ndi\params\defaultIbssChannel, min, 0, "1"
HKR, Ndi\params\defaultIbssChannel, max, 0, "11"
HKR, Ndi\params\defaultIbssChannel, step, 0, "1"
HKR, Ndi\params\defaultIbssChannel, base, 0, "10"
HKR, Ndi\params\defaultIbssChannel, type, 0, "int"
Here the default channel is shown to be 8. These are the registry values that should determine the default channel used. However, they are in the wrong section to be visible in the Advanced tab (Device Manager), so you need to copy it to the [atheros.reg] section and edit the channel you want there. (Don't forget to comment out the old section.)
After you're done, uninstall the previous driver (and unplug the device) and re-install your hacked version. Your mileage may vary.
Alternatively you can try to manually edit the registry.
BE VERY CAREFUL! (First backup your registry before attempting any changes.) As an example for registry script to import:
Windows Registry Editor Version 5.00
[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Class\{4d36e972-...-08002be10318}\0021]
"defaultIbssChannel"="8"
[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Class\{4d36e972-...-08002be10318}\0021\Ndi\params\defaultIbssChannel]
"ParamDesc"="Default Soft AP Channel"
"default"="8"
"min"="1"
"max"="11"
"step"="1"
"base"="10"
"type"="int"
Here you have to edit the \{4d36e972-...-08002be10318}\0021 part of the path, to match your own.
Related
I am currently using 'connmanctl config' to set static and DHCP settings with a wired connection. I'm curious if anyone has been successful with applying settings with the wire unplugged?
I would typically use 'connmanctl services' for a list of services then perform a string.match(blah, "ethernet_%w+_cable") to use that wired service name. I have been able to find and apply that service name with the ethernet cable unplugged BUT now when using 'connmanctl config':
connmanctl config ethernet_f8dc7a04ea82_cable --ipv4 manual 192.168.91.108 255.255.255.0 192.168.91.1 --nameservers 8.8.8.8
I get this error:
Error ethernet_f8dc7a04ea82_cable: Method "SetProperty" with signature "sv" on interface "net.connman.Service" doesn't exist
As you can see I have the service applied to the command and this is the same service name as when the cable is plugged in. This feature would be nice for equipment that needs to be pre-programmed before reaching the customer. I have also researched this error but can't find it being an issue with others the same as it is with my situation. Have also read many blogs, articles, etc...on trying to achieve this with nothing that jumps out at me.
...Any ideas ?
I had to perform this action via back-end with the code that I am using to configure. Just an example...settings are applied to /var/lib/connman/ethernet_?????cable/settings. I created the adapter name with the MAC address because it does not exist until the network is detected, created the directory /ethernet?????_cable then created an empty settings file on the fly. When programming and saving the settings via the equipment I am using I just insert the settings manually. When a network cable is plugged in and detected the settings you have applied work wonderfully.
I have built the latest version of wso2 emm android agent (cdmf-agent-android v3.1.30) and got some initial tests working in BYOD mode with IoT server 3.1.0
When built for COSU it is waiting for provisioning with another device via NFC. But I want to provision devices without NFC. What options do I have? Could I trigger programmatically a custom provisioning option?
There are some options to do this, depending on your android version.
I will start with the simplest option. If you have Android 7+ you can use QR Code provisioning, this follows the exact same process as NFC provisioning. You can see some specifications from Google regarding this.
The second option is a bit trickier and requires some custom dev on your side. First thing to to make your device a Device Owner (Which is needed for COSU mode, read up about Device Owner here). Using the command: adb shell dpm set-device-owner org.wso2.iot.agent/org.wso2.iot.agent.services.AgentDeviceAdminReceiver
Note: Only one device owner can be set, to remove a device owner the device has to be factory reset.
Once this is done you can launch your app using adb shell am start -n "org.wso2.iot.agent/org.wso2.iot.agent.activities.SplashActivity".
The above will get your app to run correctly but now it has to authenticate itself to communicate to the server. When using NFC provisioning an Access Token is delivered in the Extra Bundle as 'android.app.extra.token', you can insert this extra in the launch intent as follows: adb shell am start -n "org.wso2.iot.agent/org.wso2.iot.agent.activities.SplashActivity" --es android.app.extra.token generated_access_token. You will have to edit the SpashActivity class to accept this token and follow the general authentication processes built into the app.
This may be a little bit late but I hope it is still helpful!
Some extra information you may appreciate, here is a string representation of the NFC message used, these are the specifications set in the NFC Provisioning App:
`
#Thu Apr 12 13:42:11 GMT+02:00 2018
android.app.extra.PROVISIONING_LOCAL_TIME=1523533331087
android.app.extra.PROVISIONING_TIME_ZONE=Asia/Colombo
android.app.extra.PROVISIONING_SKIP_ENCRYPTION=true
android.app.extra.PROVISIONING_WIFI_SECURITY_TYPE=WPA
android.app.extra.PROVISIONING_WIFI_PASSWORD=PASSWORD
android.app.extra.PROVISIONING_DEVICE_ADMIN_PACKAGE_DOWNLOAD_LOCATION=LOCATION_OF_APK
android.app.extra.PROVISIONING_WIFI_SSID="WIFI_SSID_NAME"
android.app.extra.PROVISIONING_LOCALE=en_US
android.app.extra.PROVISIONING_DEVICE_ADMIN_PACKAGE_CHECKSUM=E8PtiqUOcqKi5IXeRBF-5Br0zXg
android.app.extra.PROVISIONING_ADMIN_EXTRAS_BUNDLE=\#admin extras bundle\n\#Thu Apr 12 13\:42\:11 GMT+02\:00 2018\nandroid.app.extra.token\=GENERATED_ACCESS_TOKEN\n
android.app.extra.PROVISIONING_DEVICE_ADMIN_PACKAGE_NAME=org.wso2.iot.agent
`
An example of a QR Code representation would be:
`
{
"android.app.extra.PROVISIONING_DEVICE_ADMIN_COMPONENT_NAME": "org.wso2.iot.agent/org.wso2.iot.agent.services.AgentDeviceAdminReceiver",
"android.app.extra.PROVISIONING_DEVICE_ADMIN_SIGNATURE_CHECKSUM": "CSGeivCEHdJrPT0qy4W67LZSy32Fus7GyUn0jE5o028",
"android.app.extra.PROVISIONING_DEVICE_ADMIN_PACKAGE_DOWNLOAD_LOCATION": "APK_DOWNLOAD_LOCATION",
"android.app.extra.PROVISIONING_SKIP_ENCRYPTION": false,
"android.app.extra.PROVISIONING_DEVICE_ADMIN_PACKAGE_NAME": "org.wso2.iot.agent",
"android.app.extra.PROVISIONING_ADMIN_EXTRAS_BUNDLE": {
"android.app.extra.token":"GENERATED_ACCESS_TOKEN"
}
}
`
I'm studying SDNs and using different controllers (Floodlight 1.1, OpenDaylight Lithium-SR2). I have 2 VMs which can communicate via a private network. In the first VM there is the SDN controller, while in the second VM I can setup a network topology with Mininet via a Python script.
My goal is to find out the controller behaviour: given a topology with 5 switches (with loops) and only 2 hosts, after a "ping" command, which switch does the controller select for the path between hosts?
A "ping" command in Mininet implies ARP traffic (discovering hosts' MAC addresses) and ICMP echo requests/replies.
After a ARP_REPLY we see a PACKET_IN from the switch linked to the answering host and the controller sends a FLOW_MOD message to all the switches it selects for the path, according with OpenFlow 1.0 protocol. Look at this Sequence Diagram for an example.
I captured the traffic with "tcpdump" tool and studied it with Wireshark.
Using Floodlight I can see FLOW_MOD messages which include "src" and "dst" MAC addresses (to create the path), but not with OpenDaylight (there are FLOW_MOD messages, but only before ARP traffic and only with broadcast "src" and "dst" MAC addresses).
I would like to understand why I'm not able to see FLOW_MOD messages with correct MAC addresses "src" and "dst" AFTER ARP replies (and not BEFORE). I don't know if it depends on controller's code or on OpenFlow protocol.
Thanks in advance for your help.
I found the problem: ODL works in Proactive mode as default, so I wasn't able to see Flow_Mod messages with attached MAC addresses after ARP traffic. I set ODL in Reactive mode modifying some configuration files which are located in the [ODL-folder]/etc/opendaylight/karaf/ directory of the Controller folder:
54-arphandler.xml: by default, the property <is-proactive-flood-mode>
is setted to true, so ODL works in Proactive mode. If you want Hybrid
mode set that property to false and <is-hybrid-mode> to true. If both
properties are setted to false ODL works in Reactive mode.
58-l2switchmain.xml: set the property <is-install-dropall-flow> to
false. In this way switches send packets that don't have a match (in
the switch flow table) to the controller without dropping.
Now I can see Flow_Mod messages with attached MAC addresses and check which switch is choosen by ODL to build the path between hosts.
I'm trying to use the WinUsb.sys driver that comes with Windows (including Windows 10 IoT of Raspberry Pi 2). Using devcon.exe I can see that the USB I'm trying to use is connected (it is named USB\VID_1234&PID_ABCD\5&3753427A&0&4), but I don't know how to force it to use the WinUsb.sys driver.
I found some instructions on microsoft.com but that seems to be for a standard Windows installation where you have Device Manager available (which I don't have on IoT). The INF file example on this page also refers to a CAT-file, which I assume this is some sort of driver signature, and I don't know how to generate this (or if I even need to). There's also a reference to Windows NT (Signature = "$Windows NT$") and I don't know if that needs to be changed for IoT or not (or if anything else needs to be changed for IoT for that matter).
So, using devcon.exe and some sort of INF file, how can I get Windows IoT to use WinUsb.sys as a driver for the USB device I'm attaching?
After a lot of trial and error I finally got it working. Here's a complete INF-file for future reference:
; WinUSB installation file for USB device
[Version]
Signature = "$Windows NT$"
Class = USBDevice
ClassGUID = {88BAE032-5A81-49f0-BC3D-A4FF138216D6}
Provider = %ManufacturerName%
CatalogFile = WinUSBInstallation.cat
DriverVer=09/04/2012,13.54.20.543
; ========== Manufacturer/Models sections ===========
[Manufacturer]
%ManufacturerName%=Standard,NTarm
[Standard.NTarm]
%DeviceName% =USB_Install, USB\VID_1234&PID_ABCD
; ========== Class definition ===========
[ClassInstall32]
AddReg = ClassInstall_AddReg
[ClassInstall_AddReg]
HKR,,,,%ClassName%
HKR,,NoInstallClass,,1
HKR,,IconPath,%REG_MULTI_SZ%,"%systemroot%\system32\setupapi.dll,-20"
HKR,,LowerLogoVersion,,5.2
; =================== Installation ===================
[USB_Install]
Include = winusb.inf
Needs = WINUSB.NT
[USB_Install.Services]
Include =winusb.inf
Needs = WINUSB.NT.Services
[USB_Install.HW]
AddReg=Dev_AddReg
[Dev_AddReg]
HKR,,DeviceInterfaceGUIDs,0x10000,"{ec55ee47-5758-4378-926b-68ed0aec8170}"
; =================== Strings ===================
[Strings]
ManufacturerName="The name of the company producing your device"
ClassName="Universal Serial Bus devices"
DeviceName="The name of your device"
REG_MULTI_SZ = 0x00010000
Replace the Vendor ID (VID) and Product ID (PID) in [Standard.NTarm] with the corresponding VID and PID of the USB you're adding.
Finally replace the ManufacturerName and DeviceName near the bottom with the correct info for your device.
Put this file somewhere on the Raspberry Pi 2, using either SMB or FTP.
SSH or PowerShell to the Raspberry Pi 2 and go to the folder where you put the INF file.
Run the following command: devcon dp_add .\<name of your INF file>
You should see the following result: Driver package 'oem0.inf' added.
Finally restart the RP2 (shutdown -r -t 0 from SSH/PowerShell).
When the RP2 gets back up your device should be listed under "Connected Devices" on the default startup app, and you should now be able to use functionality from Windows.Devices.Usb to communicate with the USB device.
Summary
My aim is to control the GPIO pins in Peppermint 4 Linux (Kernel version 3.8.0) on an Intel motherboard (NM70 chipset with C1037U processor).
I'm debugging issues I'm having using the sysfs interface and am trying to understand the conditions where /sys/kernel/debug/gpio would be empty?
When attempting to export pins 0 to 255 by
echo XX > /sys/class/gpio/export
for XX from 0 to 255, I get the following error message
echo: write error: No such device
Under what conditions would /sys/kernel/debug/gpio be empty?
Background
Motherboard: Intel with NM70 chipset
Processor: C1037U processor
OS: Peppermint 4 Linux
Kernel version: 3.8.0
GPIO interface: sysfs
I'm attempting to use the sysfs interface, which allows GPIO pins to be accessed from userspace through the filesystem.
I’ve successfully followed the "Alternate Build Method: The Old-Fashioned Debian Way" section of https://help.ubuntu.com/community/Kernel/Compile to recompile the kernel in order to expose GPIO access in user space and to turn on debug mode for GPIO:
Once the new kernel was compiled, I was able to see the GPIO folder in /sys/class/gpio for the first time. Then, in theory, it should be a case of being able to turn GPIO ports ON/OFF by writing to the filesystem. This approach is outlined at http://falsinsoft.blogspot.co.uk/2012/11/access-gpio-from-linux-user-space.html.
When attempting to export pins 0 to 255 by
echo XX > /sys/class/gpio/export
for XX from 0 to 255, I get the following error message
echo: write error: No such device
When attempting to export pins outside the range 0 to 255 by
echo XX > /sys/class/gpio/export
I get the following error message
echo: write error: Invalid argument
The tutorial suggests this could be because the GPIO ports are reserved for another program and that, if so, the debug file (/sys/kernel/debug/gpio) would be able to show where they are reserved.
However, /sys/kernel/debug/gpio is empty.
I can see and control the GPIO pins in the BIOS (change pins to be input or output HIGH/LOW).
Related questions
writing to /sys/class/gpio/export failing
Enable pullup GPIO
/sys/kernel/debug/gpio will be empty if there no GPIO device registered (warning: when I say GPIO device, I don't mean the piece of hardware, but rather the kernel representation of it).
So, these GPIO devices are registered at runtime by the kernel and associated to a specific GPIO device driver.
In turn, the GPIO device driver is selected and associated to a given device, because it is the one declaring compatibility with said GPIO device.
E.g., the kernel would match on PCI vendor and product ID, and probe a GPIO driver that claims support for that PCI vendor/product. When the GPIO driver is probed, it typically registers the GPIO device instance.
Finally, that registered GPIO device is what provides GPIOs shown in /sys/kernel/debug/gpio.
The above is part of the so-called "Device Driver model" in Linux. Although it's a bit outdated, you can read [1].
Now, let's see what GPIO driver you need to select for your NM70 chipset. Wikipedia says that the chipset codename is "Panther Point-M" [2]. With some luck, the lpc_ich driver could support it. You would have to build your kernel with CONFIG_LPC_ICH=y.
Alternatively, if your GPIOs are provided by a PCI device, you could use lspci to get the IDs, and then grep in the kernel sources for those IDs.
[1] http://www.oreilly.com/openbook/linuxdrive3/book/ch14.pdf
[2] https://en.wikipedia.org/wiki/List_of_Intel_chipsets