Linux.com

Home Linux Community Community Blogs

Community Blogs



MakeDongle Protects Mac, Windows or Linux Software with a USB Dongle

Excel Software announced MakeDongle 1.0 that runs on Mac or Windows computers.  MakeDongle generates a secure USB dongle that grants a license to run protected software on the attached Mac, Windows or Linux computer.  MakeDongle complements a diverse suite of protection and licensing tools.

Protected software can be stored on the computer or dongle itself.  When launch, the dongle is validated before the software is allowed to run.  When building dongles, MakeDongle can copy multiple licenses, applications or installers to the USB drive.  A dongle without additional software can be generated in seconds.

MakeDongle can be used standalone or with the QuickLicense, AppProtect or DocProtect products.  It also works with licensing plugins for FileMaker and Xojo.  To use MakeDongle alone, add a programming command to Mac or Windows software.  Several coding interfaces are supported with sample code provided for popular programming languages.

MakeDongle works with QuickLicense.  QuickLicense supports many license types including Trial, Product, Try/Buy and Subscription.  Software is protected by adding API programming commands or by using the AddLicense wrapping tool without programming.  

AddLicense is a popular choice for runtime environments like MAX or Unity since application code and resources can be securely embedded within the EXE or APP file.  Protected software can immediately launch when the appropriate dongle is present or first require a manual or online activation process.  MakeDongle and QuickLicense give developers many options for software and hardware protection.

MakeDongle works with QuickLicenseRT Linux.  QuickLicense and MakeDongle run on a Mac or Windows computer to produce a dongle and license files.  The protected Linux software works on a Linux computer with the dongle installed in any free USB port.

MakeDongle works with AppProtect.  AppProtects wraps a Mac or Windows software into a protected application that runs when the dongle is installed.  An optional computer unique password or online activation can be required.

MakeDongle works with DocProtect.  DocProtect wraps PDF, EPUB, Video, SWF or HTML files into a Mac or Windows application.  The protected document can be used on any computer when the dongle is installed.  An optional computer unique password or online activation can be required.  MakeDongle, DocProtect and QuickLicense can be combined to support other license types and features.

Excel spreadsheets can be protected using QuickLicense and OfficeProtect to produce an EXE for Windows or APP for Mac.  This protection can be combined with a USB dongle that determines what computer can run the application.  The application and encrypted data files can be stored on the dongle making them easily portable between computers.

MakeDongle 1.0 is $395 for a Single User License on Mac or Windows.  MakeDongle can be used to produce unlimited dongles for any number of products.  The product includes royalty-free distribution rights for protected Mac or Windows software that uses the included MakeDongle standalone API.  MakeDongle MacOSX runs on 10.7 or later.  MakeDongle Windows runs on Windows Vista, 7, 8 or 8.1 but can produce dongles that also work on Windows XP.  Visit the company web site for demonstration videos and product information.

Excel Software
Ph: (702) 445-7645
Web: www.excelsoftware.com
Email: This e-mail address is being protected from spambots. You need JavaScript enabled to view it

 

Linux Kernel 3.19.2 Stable Released With Updated Drivers And More, Install In Ubuntu/Linux Mint


Linux Kernel 3.19.2 Stable Released install in ubuntu/linux mint

Greg Kroah-Hartman released Linux Kernel 3.19.2 with various changes and improvements. Greg Kroah-Hartman suggests all Linux Kernel 3.19 users to update to 3.19.2. The release having several updated drivers, and a list of changes and improvements can be foundhere. You can follow the tutorial to install/update to 3.19.2.
 

Read At LinuxAndUbuntu

 

How to deploy OnlyOffice on server with ease using Docker service

A couple of words about the product

OnlyOffice groupware is aimed at small and medium business and consists of the following tools: Project and document management; Gantt Chart; CRM and Invoicing; Mail Aggregator. Moreover, it implies third-party services integration such as Box, Sharepoint, OwnCloud to create a single workspace.

The product is cross-platform and you can choose the appropriate installation file + take a screentour here: https://www.onlyoffice.com/open-source.aspx

Docker service

Working on the Linux version we tried to do our best to simplify this process and used Docker as an Aladdin's lamp - open-source project that automates the deployment of applications inside software containers.

To work correctly ONLYOFFICE requires some additional components to be installed on the machine, like Mono version 3.2 or later, MySQL version 5.6 or later etc. (the full system requirements list can be found here).

Docker container comprises not only ONLYOFFICE but also all dependencies necessary for its correct work. All you need besides love is to execute one single command.

Good news: OnlyOffice installation process takes just a few minutes - music to Linux new comers ears, and for eyes as well: https://www.youtube.com/watch?v=LvFffFIawa8.

Installing ONLYOFFICE

Run Docker and execute the following command:

sudo docker run -i -t -d -p 80:80 ascensiosystemsia/onlyoffice-commonserver

This command will download the dockerfile from Docker Hub and launch the container running ONLYOFFICE and all the dependencies necessary for its work.

Configuring ONLYOFFICE

If you wish to run ONLYOFFICE on a different port, change the value of the -p command. For example, to run your office on 8080 port, use the following command:

sudo docker run -i -t -d -p 8080:80 ascensiosystemsia/onlyoffice-commonserver

To prevent unauthorized access to the information, you can secure the access to ONLYOFFICE using SSL (HTTPS). To do that, execute the following command:

sudo docker run -i -t -d -p 80:80 -p 443:443 -v /opt/onlyoffice/Data:/var/www/onlyoffice/Data ascensiosystemsia/onlyoffice-commonserver

In this case you will need to create and install the following files:

/opt/onlyoffice/Data/certs/onlyoffice.key

/opt/onlyoffice/Data/certs/onlyoffice.crt

The step by step instructions on how it can be done are available on the ONLYOFFICE profile page of Docker official website.

Running ONLYOFFICE

After everything is installed, you can open your portal in the web browser at the localhost address (http://127.0.0.1) on the local machine. The Welcome page will open.

Enter a password and specify the email address you will use to access your ONLYOFFICE the next time. To complete the activation process, just follow the link provided in the email that will be sent at the specified email address.

That is all! Djinn is out - you can start working in your office!

Share your experience with us if it was a kind of magic for you too.

If Djinn got stuck in the lamp, we invite you to visit ONLYOFFICE Developers forum: http://dev.onlyoffice.org/

 

Ffmpeg media converting guide

 

 

FFmpeg Converting Guide

 

 I noticed some people have problems with ffmpeg very basic commends so I decided to make an article that will provide with very basic information and commends that will help people use ffmpeg.

 

 First we need to get FFmpeg for our system, there are multiple ways to get it but I would recommend getting the binary files you can get it from here (Windows, Linux, Mac) This video will help you understand how we will use our ffmpeg

 

 Second understand the difference between Digital container format (.mkv, .mp4, .avi) and video compression format / Audio compression format (H.264, Vp9, AAC) Container format is a thing were you put your compression format in. Note that not every compression format can be placed in any container formats.

 

 Third lets look at very basic commends

 

-b:v  -Target video bitrate
 
-b:a  -Target Audio bitrate

 

-r    -specify frame rate of video example -r 60 (video frame rate will be 60) 

 

-vf scale=1920:1080   -change the resolution of the video (16:9 or 4:3 resolutions)
 
-aspect 16:9    -force aspect ration, even though you might have 4:3 resolution you can force aspect ration like this
 
 

 

1) Convert video file to Audio file 

example video to mp3

 

ffmpeg -i input_movie.mp4 -acodec libmp3lame -b:a 192k output.mp3

 

libmp3lame

is a audio compression format (mp3) you can change to a different one but make sure that you put it a the correct container format.

 

example:

 

AAC - Advanced Audio Coding - libvo_aacenc

 

ffmpeg -i input_movie.mp4 -acodec libvo_aacenc -b:a 192k output.aac

 

ogg - Vorbis - libvorbis

 

ffmpeg -i input_movie.mp4 -acodec libvorbis -b:a 192k output.oga

 

 

You can go on and go on like this For compression format just change lib* file to a different one and for bit rate just change 192k to what ever you want for example 128k, 256k,

 

2) Convert a video file into a different one

example to x264

 

ffmpeg -i input_movie.mp4 -c:v libx264 -b:v 2567k -c:a libmp3lame -b:a 192k output.mp4

 

libx264

Is a video compression format just like in audio compression format you can change this as well, and you can change the audio compression format as well.

make sure that you put it in a correct container format.

 

example:

 

mpeg2 - mpeg2video

 

ffmpeg -i input_movie.mp4 -c:v mpeg2video -b:v 2567k -c:a libmp3lame -b:a 192k output.mpg

 

Vp9 - libvpx-vp9

 

ffmpeg -i input_movie.mp4 -c:v libvpx-vp9 -b:v 2567k -c:a libvorbis -b:a 192k output.mkv

 

x265 - libx265

 

ffmpeg -i input_movie.mp4 -c:v libx265 -b:v 2567k -c:a libvorbis -b:a 192k output.mkv

 

xvid - libxvid

 

ffmpeg -i input_movie.mp4 -c:v libxvid -b:v 2567k -c:a libvorbis -b:a 192k output.mkv

 

You can go on and go one like this as you can see it is very simple just change lib* to what ever you want and for bit rate just change 192k to what ever you want for example 128k, 256k,

 

 

One more thing lats make one commend a bit hard to show you how easy it really is

 

ffmpeg -i input_movie.mp4 -vf scale=640:480 -aspect 16:9 -r 120 -c:v libx264 -b:v 13976k -c:a libmp3lame -b:a 192k output.mkv

 

 

-vf scale=640:480 

With this I resized the video resolution to 640:480

 

-aspect 16:9

Even though 640:480 is a 4:3 aspect ration resolution with -aspect 16:9 I forced the video to be 16:9

 

-r 120

I changed the video frame rate to be 120 FPS

 

 

See how easy it is.

 

 

3) Cut (Change) video length

 

 ffmpeg -i in.mp4 -ss [start] -t [duration] -c:v copy -c:a copy out.mp4
 

Example

 ffmpeg -i in.mp4 -ss 00:01:15 -t 00:00:10 -c:v copy -c:a copy out.mp4
 

Running this command will not encode your  video it will copy the video and the only difference will be the durations of the video as you specified

 

4) Extract an image out of your video

 

 

 ffmpeg -i input_movie.mp4 -ss 00:00:05 -f image2 -vframes 1 imagename.png
 
5) Create Video Thumbnails 
 
ffmpeg -ss 00:00:01 -i yourvideofile.avi -frames 1 -vf "select=not(mod(n\,240)),scale=512:288,tile=4x7" out.jpg
 
 

 - ss 00:00:01 means that it will start from first second of course you can tweak it

 

yourvideofile.avi this is where you should put your video file it can be .avi .mp4 just about any format because ffmpeg supports a lot of formats

 

240 means that it will take a screenshot every 240 frames of caures you can  adjust to your preferences. for example if your video is 30 fps and you have 240 then it means that it will take a shoot every 8 seconds.

 

512:288  now this is a scale of every individual image in the gallery you can adjust it but note that if your video is 16:9 you should select a resolution that is 16:9 see this list if your video is 4:3 look at this list make sure to select proper aspect ratio.

 

4x7 this means that it will put 4 horizontal and 7 vertical images on the final outputted imag. of course you can edit this 

 

out.jpg here you can use other image compression methods like .png etc..

 

make sure the spacing the latter cases are exactly the same

 

6) Join Video and Audio files

 

ffmpeg -i video.mp4 -i audio.mp3' -c:v copy -c:a copy -map 0:v:0 -map 1:a:0 output.mp4

 

 

 

You can see how easy it is to work with ffmpeg, all of this is not even scratching the boom of the ffmpeg capabilities and the Internet is a great place to get more information.

 

Video compression format comparison.

 

FFmpeg man page

 

MIPS Creator CI20 v Raspberry Pi 2

Imagination Technologies is a British company that has recently entered full production of a board based on MIPS computer architecture. The single-board computer has been designed to allow developers to create applications for mobiles, gaming, Internet of Things, and wearables.

The MIPS Creator CI20 is billed as a high-performance, fully featured Linux and Android development platform. The board includes an Ingenic JZ4780 SoC which is built around a dual-core MIPS32 processor clocked at 1.2GHz, and Imagination's PowerVR SGX540 GPU. The Creator CI20 comes with a price tag of $65 or £50, which is significantly more expensive than the Raspberry Pi 2.

<A HREF="http://www.linuxlinks.com/article/20150315065630654/MIPSCI20.html">Read on</A>

 

Notice on TN11PIU Wrongly Reported THUNDERALM Alarm on OptiX OSN 6800

Summary:
When the TN52SCC board is used on OptiX OSN 6800, the power module of the TN11PIU board interferes with lightning protection alarm signals. As a result, a detection error occurs and the THUNDERALM alarm is wrongly reported.

OSN 6800

[Problem Description]
Trigger condition:
The TN52SCC board is used on DWDM Huawei OptiX OSN 6800 and the fan tray assembly is running at high speed.

Symptom:
When the TN52SCC board is used on OptiX OSN 6800 and the fan tray assembly is running at high speed, the TN11PIU board reports a THUNDERALM alarm.

Identification method:
When the OptiX OSN 6800 uses the TN52SCC board, identify the problem as follows:
1. Set the fan tray assembly to low speed. The THUNDERALM alarm is cleared 10 seconds later.
2. Set the high speed again. The alarm is reported 10 seconds later.
If the preceding symptoms occur, the alarm is wrongly reported and the TN11PIU board is involved in the problem.
Note: After the above identification operations are completed, you must restore the fan try assembly speed to prevent impact on NE heat dissipation.

[Root Cause]
The power module of the TN11PIU board supplies power to the fan tray assembly. If the fan tray assembly is running at high speed, the load current of the power module is great and the power module noise is increased accordingly, interfering with lightning protection signals. If at this time the TN52SCC board is used, it detects lightning protection signals at a high frequency. Therefore a detection error occurs and the THUNDERALM alarm results. If the TN51SCC board is used, it detects the signals at a low frequency and therefore no detection error or related alarm results. If the fan tray assembly is running at low speed, the load current of the power module is small and therefore the power module noise is small. Therefore, no detection error or related alarm results.

[Impact and Risk]
If an error occurs in detecting the lightning protection signals, the THUNDERALM alarm will be wrongly reported by the TN11PIU board but services are not affected.

[Measures and Solutions]
Recovery measures:
None.
Workarounds:
None.
Preventive measures:
Not available currently. If any preventive measure is available, the notice will be updated.
Material handling after replacement:
None.

 

Linux Wireless Networking: a short walk

How does Linux wireless interface with the kernel? How are packets transmitted / received?

When I started working on Linux wireless, I was lost in the immense code base, and I was looking for an introductory material that can answer high-level questions like above. After tracing through the source codes, I put down this summary in the hope that it can be helpful as an overview of how things work in Linux wireless networking. 

 

Overview

To begin the walk, let’s first have an overview of the architecture in Fig. 1, which should show the high-level blocks in Linux kernel networking, and how Linux wireless fits into the kernel. 

 arch

Fig. 1: Overview of Linux wireless networking architecture

The bulk of Fig. 1 shows the kernel space. The user space applications are running on top of it, and the hardware devices are at the bottom. On the left are Ethernet devices, and on the right are WiFi devices.

There are two types of WiFi devices, depending on where IEEE802.11 MLME is implemented. If it is implemented in device hardware, the device is a full MAC device. If it is implemented in software, the device is a soft MAC device. Most devices today are soft MAC devices.  

Often, we can think of the Linux wireless subsystem to contain two major blocks: cfg80211 and mac80211, and they help the WiFi driver to interface with rest of the kernel and user space. In particular, cfg80211 provides configuration management services in the kernel. It also provides management interface between kernel and user space via nl80211. Both soft MAC and full MAC devices need to work with cfg80211. Mac80211 is a driver API that supports only software MAC devices. Our focus here will be on soft MAC devices, as shown in Fig. 1.

The Linux wireless subsystem, together with WiFi devices, deals with the bottom two layers (MAC and PHY) of the OSI model. For a more refined breakdown, the MAC layer can be further divided into upper MAC and lower MAC, where the former refers to the management aspect of the MAC (e.g. probing, authentication, and association), and the latter refers to the time critical operations of MAC such as ACK. Most of the time, the hardware, such as WiFi adapters, deals with majority of PHY and lower MAC operations, and the Linux wireless subsystem largely handles the upper MAC.

 

Interface among Blocks

The blocks in Fig. 1 have clearly defined boundaries, and support transparency, which means what happens in one block should not affect others. For example, we may make some changes in the WiFi driver block (e.g. applying a patch, or even adding a new driver for new device), but such changes does not affect the mac80211 block, and we do not need to change the codes in mac80211. As another example, adding a new network protocol should ideally not change the codes in socket layer and device agnostic layer. Such transparency is often achieved through function pointers. An example of how a WiFi driver (rt73usb) interfaces with mac80211 is:

static const struct ieee80211_ops rt73usb_mac80211_ops = {         .tx                     = rt2x00mac_tx,         .start                  = rt2x00mac_start,         .stop                   = rt2x00mac_stop,         .add_interface          = rt2x00mac_add_interface,         .remove_interface       = rt2x00mac_remove_interface,         .config                 = rt2x00mac_config,         .configure_filter       = rt2x00mac_configure_filter,         .set_tim                = rt2x00mac_set_tim,         .set_key                = rt2x00mac_set_key,         .sw_scan_start          = rt2x00mac_sw_scan_start,         .sw_scan_complete       = rt2x00mac_sw_scan_complete,         .get_stats              = rt2x00mac_get_stats,         .bss_info_changed       = rt2x00mac_bss_info_changed,         .conf_tx                = rt73usb_conf_tx,         .get_tsf                = rt73usb_get_tsf,         .rfkill_poll            = rt2x00mac_rfkill_poll,         .flush                  = rt2x00mac_flush,         .set_antenna            = rt2x00mac_set_antenna,         .get_antenna            = rt2x00mac_get_antenna,         .get_ringparam          = rt2x00mac_get_ringparam,         .tx_frames_pending      = rt2x00mac_tx_frames_pending,}; 

On the left are the API in the form of struct ieee80211_ops that mac80211 provides to the WiFi device drivers, and it is up to the drivers to implement these handlers. Of course, different devices will have different driver implementations. The struct ieee80211_ops keeps the mapping between driver implementation of the handlers to the common mac80211 API. During driver registration, these handlers are registered to the mac80211 (through ieee80211_alloc_hw), and mac80211 can then blindly invoke a handler without knowing its name and detailed implementations.  The original struct ieee80211_ops contains a long list of APIs, but not all of them are mandatory. For successful compilation, implementing the first seven APIs is sufficient, but for proper functioning, some more APIs may need to be implemented, as in the example above.

 

Data Path and Management Path

From Fig. 1, there are two major paths in the architecture: a data path, and a management path. The data path corresponds to the IEEE 802.11 data frames, and the management path corresponds to the IEEE 802.11 management frames. For IEEE802.11 control frames, as most of them are used for time-critical operations such as ACK, they are often handled by the hardware. An exception may be the PS-Poll frame, which can also be taken care of by mac80211. The data and management paths are split in mac80211.

 

How is data packet transmitted?

Here we focus on the data path for transmission. 

Starting from user space application, often we create a socket, bind it to an interface (e.g. Ethernet or WiFi), put the content into socket buffer, and send it. In socket creation, we also specify its protocol family, which will be used by the kernel. This happens in the data application block in Fig. 1. Eventually this invokes a system call, and subsequent work happens in the kernel space.

The transmission first passes the socket layer, and an important structure here is struct sk_buff, or more commonly known as skb. A skb holds pointer to the data buffer and tracks the data length. It provides very good support and APIs to transfer our data among different layers in the kernel, such as header insertion/removal, and is used thoughout the packet transmission / reception process.

We then pass the network protocol block. There is not much to say about the networking protocols because there is too much to say about the networking protocols. The protocols are really not the focus here, and it suffices to know that the transmission is mapped to a networking protocol according to the protocol specified during socket creation, and the corresponding protocol will continue to handle the transmission of the packet.

Now the transmission lands itself at the device agnostic layer, which links various hardware devices like Ethernet and WiFi to different network protocols, transparently. The device agnostic layer is characterized by an important structure: struct net_device. This is how Ethernet device drivers interface with the kernel, as shown by the Ethernet driver block in Fig. 1. The interfacing is via struct net_device_ops, which has a long list of net_device operations. Particularly for transmit:

struct net_device_ops

… 

netdev_tx_t(*ndo_start_xmit) (struct sk_buff *skb, struct net_device *dev); 

};

 

To send the packet, the skb is passed to a function called dev_queue_xmit. After tracing through the call, it eventually invokes ops->ndo_start_xmit(skb, dev). This is exactly the API handler that Ethernet device drivers need to register.

For WiFi devices, however, it is usually mac80211 (instead of the device drivers) that registers with netdev_ops. See net/mac80211/iface.c:                  

static const struct net_device_ops ieee80211_dataif_ops = {        .ndo_open               = ieee80211_open,        .ndo_stop               = ieee80211_stop,        .ndo_uninit             = ieee80211_uninit,        .ndo_start_xmit         = ieee80211_subif_start_xmit,        .ndo_set_rx_mode        = ieee80211_set_multicast_list,        .ndo_change_mtu         = ieee80211_change_mtu,       .ndo_set_mac_address    = ieee80211_change_mac,       .ndo_select_queue       = ieee80211_netdev_select_queue,};

So mac80211 also appears as a net_device, and when a packet needs to be transmitted via WiFi, the corresponding transmit handler, ieee80211_subif_start_xmit, is invoked, and we are entering the mac80211 block.  Below is the call trace for ieee80211_subif_start_xmits. Subsequently it invokes:

ieee80211_xmit => ieee80211_tx => ieee80211_tx_frags => drv_tx
We are now at the boundary between mac80211 and WiFi driver. The drv_tx is simply a wrapper that maps the transmission to the tx handler that WiFi device driver has registered:
static inline void drv_tx(struct ieee80211_local *local, struct ieee80211_tx_control *control, struct sk_buff *skb){        local->ops->tx(&local->hw, control, skb);}

 

This is the end of mac80211, and device driver will take over.  

As mentioned previously, through the mac80211 local->ops->tx, the registered handler in the device driver is invoked. Each driver has it unique implementation of the handler. Following the previous example in Interface among Blocks, the tx handler is rt2x00mac_tx, which first prepares the transmit descriptor normally including information such as  frame length, ACK policy, RTS/CTS, retry limit, more fragments, and MCS, etc. Some information is passed down from mac80211 (e.g. in struct ieeee80211_tx_info, which in this case tells the device driver what to do), and the driver has to convert the information into a form that its underlying hardware can understand. Once the device specific transmit descriptor is done, the driver may condition the frame (e.g. adjust byte alignment), put the frame on a queue, and eventually send the frame (and its transmit descriptor) to hardware. As our example is a USB WiFi adapter based on rt73usb, the frame is sent via the USB interface to the hardware, which further inserts the PHY header and other information and transmits the packet to the air. The driver may also need to feedback the transmit status (also via struct ieee80211_tx_info) to mac80211 by invoking ieee80211_tx_status, or one of its variants. This also marks the end of packet transmission.

 

 

What about management path?

Theoretically we can transmit management frames the same way as in data path by constructing management frames in user space and send them via socket, but there are well-developed user space tools, notably wpa_supplicant and host_apd, that can do the work. Wpa_supplicant controls the wireless connection for client STAs such as scan, authentication, and association, whereas host_apd functions as AP. These user space tools uses netlink socket to communication with the kernel, and the corresponding handler in the kernel is nl80211 in cfg80211. These user space tools will invoke the send handlers in netlink library to send command (e.g. NL80211_CMD_TRIGGER_SCAN) to the kernel. In kernel space, the command is received by nl80211, which has the mapping between command (.cmd) and action (.doit) in static struct genl_ops nl80211_ops:

static const struct genl_ops nl80211_ops[] = {

…        

{                

.cmd = NL80211_CMD_TRIGGER_SCAN,                

.doit = nl80211_trigger_scan,                

.policy = nl80211_policy,                

.flags = GENL_ADMIN_PERM,                

.internal_flags = NL80211_FLAG_NEED_WDEV_UPNL80211_FLAG_NEED_RTNL,        

},

};

 

For the example of triggering scan, the scan request is passed from cfg80211 to mac80211 via the scan handler that mac80211 has registered with cfg80211 in struct cfg80211_ops:

const struct cfg80211_ops mac80211_config_ops = {

…     

 .scan = ieee80211_scan,

};

In mac80211, ieee80211_scan will take over the scanning process:

=>ieee80211_scan_state_send_probe 

=>ieee80211_send_probe_req

=>ieee80211_tx_skb_tid_band

=>ieee80211_xmit

=>ieee80211_tx

=>ieee80211_tx_frags

=>drv_tx

 

How is received packet handled?

We are now traveling in the reverse direction for packet reception. For the moment we do not differentiate between data and management path.

When a packet is captured by the WiFi hardware over the air, the hardware may generate an interrupt to the kernel (e.g. as in most PCI interfaces ), or the packet may be polled (e.g. for the case of USB interface). In the former case, the interrupt will lead to a receive interrupt handler, and for the latter, a receive callback handler is invoked.

It turns out that in these handlers the device driver does not do much with the received packet except for some sanity check, filling up the receive descriptor for mac80211, and then passing the packet to mac80211 for further processing (either directly or more commonly putting the packet on a receive queue).

Entry to mac80211 is via ieee80211_rx or one of its variants, which invokes various receive handlers in mac80211 (see in ieee80211_rx_handlers for the code). This is also where the data path and management path are divided.

If the received frame is of type data, it is translated into 802.3 frame (by __ieee80211_data_to8023) and is delivered to the networking stack via netif_receive_skb. From then on, the network protocol block will parse and decode the protocol header.

If the received frame is of type management, it is processed in ieee80211_sta_rx_queued_mgmt. Some management frames end in mac80211, and some are further passed up to cfg80211 and sent to user space management tools. For example authentication frames are further processed by cfg80211_rx_mlme_mgmt and sent to user space via nl80211_send_rx_auth, and association response frames are processed by cfg80211_rx_assoc_resp and sent to user space via nl80211_send_rx_assoc.

 

Concluding the Walk

The typical flow pattern of a WiFi driver contains three tasks: configuration, transmit path handling, and receive path handling. Take again the USB WiFi adapter for example, when the device is detected, the probe function is invoked. This could be where the configuration like registration of ieee80211_ops takes place:

First, ieee80211_alloc_hw allocates a struct ieee80211_hw, which represents the WiFi device. In particular, the following data structures are allocated:

  • - struct wiphy: mainly used to describe WiFi hardware parameters like MAC address, interface modes and combinations, supported bands, and other hardware capabilities.  
  • - struct ieee80211_local: this is the driver visible part and is largely used by mac80211. The mapping of ieee80211_ops is linked to the struct ieee80211_local (const struct ieee80211_ops *ops of struct ieee80211_local). It can be accessed from ieee80211_hw by using container_of, or the API hw_to_local.
  • - Private struct for device driver (void *priv in struct ieee80211_hw).
Registration of the hardware is completed through ieee80211_register_hw, after which other mac80211 functions takes place. For example, in STA mode, wpa_supplicant will instruct the device to scan, authenticate, and associate with a BSS and subsequently data communication will occur.

Hopefully, with this overview, tracing through the source codes would be easier.

 

References:

Linux wireless subsystem: https://wireless.wiki.kernel.org/en/developers/documentation

 

How To Install Tor Browser 4.0.4 In Linux To Surf Anonymously


How To Install Tor Browser 4.0.4 In Linux To Surf Anonymously

Are you worried for the information that you're sharing with the Agencies like, National Security Agency (NSA) and more? You want privacy and security! Here it comes Tor Browser that will fit into your needs. Tor is free, open network browser based on Mozilla Firefox that serves the purpose of beinganonymous and secure. 
 

Read At LinuxAndUbuntu

 

Cautions for CF Card Failure on TN11SCC in OptiX OSN 6800

Summary:
When the TN11SCC board is in V100R004C01 or an earlier version, the lifecycle of the CF card on the board may be shorter than expected.

[Problem Description]
Trigger condition:
Periodical database and log backup, and upgrade in package loading mode on the Huawei dwdm board TN11SCC are properly implemented.

Symptom:
An SWDL_NEPKGCHECK alarm is reported.

Identification method:
The CF card is faulty when all the following conditions are met:
1. The TN11SCC board is in V100R004C01 or an earlier version.
2. The CF card has been used for more than five years.
3. An SWDL_NEPKGCHECK alarm is reported.
4. The access to the cfs1 area of the board fails using a command on the Navigator. For example, a board in slot 18 reports an SWDL_NEPKGCHECK alarm as shown in the following figure..

SWDL_NEPKGCHECK alarm

A command on the Navigator is delivered as shown in the following figure.

Navigator

However, a failure message is returned. When this occurs, the CF card has been faulty.

[Root Cause]
As confirmed by the CF card supplier WD, the CF card will become faulty upon multiple times of rewrite operations and cannot be read or write any longer. Since there are frequent
database and log backup operations for Huawei OptiX OSN 6800 V100R004C01 and earlier versions, the CF card can be used for five years at most. The card lifecycle is closely related to the size of the NE database and logs. In versions later than V100R004C01, the backup frequency and method are modified. After the modification, the CF card can be used for at least 100 years as estimated.

[Impact and Risk]
Upgrade in package loading mode and software synchronization will be affected, but services are not affected.

[Measures and Solutions]
Recovery measures:
Replace the TN11SCC board when the CF card of the board becomes faulty.

Workarounds:
Before the CF card becomes faulty, upgrade the TN11SCC board to V100R004C04SPC800 or
a later version.

Preventive measures:
1. If the CF card on a TN11SCC board has been faulty, replace the board. For more Huawei transmission board please have reference on www.thunder-link.com
2. If the CF card has not been faulty, upgrade the TN11SCC board to V100R004C04SPC800 or a later version.

Material handling after replacement:
Return the TN11SCC board for repair.

 

Meet Fedora 21 Xfce Desktop Environment

Fedora 21 XFCE is fedora 21 featuring XFCE desktop version 4.10, include applications that will enhance your productivity. Xfce is a lightweight desktop environment that is designed to be speedy, It loads and executes applications fast, while conserving system resources. The Fedora Xfce Spin is a high-quality Xfce experience for Fedora users and developers. Enjoy the benefits of the Xfce desktop's clean and quick interface. Get more done faster, and run your desktop on this innovative Fedora platform.

The default applications include in Fedora 21 Xfce : Thunar File manager 1.6.3, xfce4-terminal 0.6.3, ristretto 0.6.3, Clipman 1.2.6, xarchiver 0.5.2, geany 1.24.1, Document Viewer 3.14.1, clawmail 3.11.1, pidgin IM 2.10, Transmission 2.84, Midori 0.5.9, parole media player 0.5.4, Pragha Music Player 1.2.2, Xfburn 0.5.2, abiword 3.0, Yum Extender 3.0.16.

Fedora 21 XFCE video overview and screenshot tours

 

Fedora 22 Alpha Released And Available To Download


Fedora 22 Alpha Released And Available To Download

Feodra 22 Alpha release has been announced with many changes included. Fedora only releases two developments releases before the final one. The next release will be beta in April and the final Fedora will be released in May, 19, if everything goes well. Let's look at the first development release Alpha.
 

Read At LinuxAndUbuntu

 
Page 5 of 158

Upcoming Linux Foundation Courses

  1. LFS201 Essentials of System Administration
    12 Jan » 30 Mar - Online Self-Paced
    Details
  2. LFS220 Linux System Administration
    18 May » 21 May - Virtual (GUARANTEED TO RUN)
    Details
  3. LFS230 Linux Network Management
    25 May » 28 May - Virtual
    Details

View All Upcoming Courses


Who we are ?

The Linux Foundation is a non-profit consortium dedicated to the growth of Linux.

More About the foundation...

Frequent Questions

Join / Linux Training / Board