tel: +972-9-766-0456 fax: +972-9-766-0461 release notes · qualcomm 3g cdma icon 225 huawei ec1260...

Connect One

Preliminary

June 2011

Release Notes

iChip OS Version i2128D809B01

Revision 1.00

Reference Version: 807B21

20 Atir Yeda Street 1st

floor Kfar Saba 44643 Israel

Tel: +972-9-766-0456

Fax: +972-9-766-0461

www.connectone.com

Version i2128D809B01 Release Notes 2

Table of Contents 1. WHAT IS NEW IN RELEASE 809B01? ...................................................................................... 3

1.1 SUPPORT FOR ADDITIONAL USB MODEMS .................................................................................. 3 1.2 CONCURRENT LAN AND WIFI COMMUNICATION PLATFORMS .................................................... 3

1.2.1 Introduction ............................................................................................................................ 3 1.2.2 Current Ethernet/WiFi Rules and Operation .......................................................................... 4 1.2.3 iRouter Mode .......................................................................................................................... 5 1.2.4 Host PPP Mode ...................................................................................................................... 6 1.2.5 iChip Network Services........................................................................................................... 7 1.2.6 New Ethernet+WiFi mode of Operation ................................................................................. 7 1.2.7 DHCP Server when +iLTYP=4 .............................................................................................. 9 1.2.8 DNS Parameter when +iLTYP=4 ........................................................................................... 9 1.2.9 Routing Mode when +iLTYP=4............................................................................................ 11 1.2.10 The following table summarizes the routing and NAT translation rules: ........................ 12 1.2.11 Example Use Case ........................................................................................................... 13

1.3 DYNAMIC DNS SUPPORT ........................................................................................................... 15 1.3.1 Introduction .......................................................................................................................... 15 1.3.2 DynDNS Registration ........................................................................................................... 15 1.3.3 iChip Interface for DynDNS ................................................................................................. 16

1.4 NEW REPORT: KEEP-ALIVE TASK STATUS ................................................................................. 17 1.5 NEW REPORT: CELLULAR SIGNAL QUALITY .............................................................................. 17 1.6 IGNORE DISCONNECT EVENTS IN WIFI ROAMING MODE ........................................................... 18 1.7 CONNECT TO ANY INTERNET ENABLED AP ................................................................................ 19 1.8 NEW BEHAVIOR WHEN SETTING +IWLSI OR +IWLPP ............................................................... 20 1.9 USE CERTIFICATE‟S SUBJECT COMMON-NAME AS +IEUSN IN ENTERPRISE MODE ................... 20 1.10 PROXY SERVER IMPROVEMENTS ................................................................................................ 21 1.11 SEND AND RECEIVE SMS MESSAGES ......................................................................................... 22 1.12 SSL SERVER LISTEN SOCKET ..................................................................................................... 26

1.12.1 Introduction ..................................................................................................................... 26 1.13 WAKEUP ON SMS ...................................................................................................................... 28 1.14 CONTROLLING THE VBUS SIGNAL ............................................................................................... 28

1.14.1 Introduction ..................................................................................................................... 28 1.14.2 iChip VBUS Control ........................................................................................................... 28

1.15 NEW MTYP VALUE FOR GSM MODEM TC65I ........................................................................... 30 1.16 NEW CPIN PARAMETER ............................................................................................................. 30 1.17 ADDITIONAL DIRECT-MODEM AT+I COMMANDS ...................................................................... 30

2 LIMITATIONS SOLVED ........................................................................................................... 33

3 KNOWN LIMITATIONS IN 809B01 ......................................................................................... 34

4 SUPPORTED PLATFORMS ...................................................................................................... 35

5 FIRMWARE FILE INFORMATION......................................................................................... 35

Connect One


1. What is New in Release 809B01?

1.1 Support for Additional USB Modems

Additional USB modems are now supported by iChip‟s USB host. Following is the

updated list of pre-qualified USB modems: SIMCON 5218E

Siemens HC25

Qualcomm 3G CDMA iCON 225

HUAWEI EC1260 (E620 USB Modem)

HUAWEI EC169 (E620 USB Modem)

HUAWEI EM660

HUAWEI EM770

HUAWEI EM560

ZTE MF622

ZTE MF626

ZTE MF636

ZTE MF637

ZTE MF626

ZTE AC580

ZTE AC2716

ZTE AC8710

ZTE AC2726

ZTE AC2736

ZTE AC8700 (EV-DO)

ZTE AC8710

ZTE HSDPA Z100M (ZTE AD3801)

DTmobile DTM6211

U6100 LONGSUNG

Longsung U5100

LongCheer U5300

Iridium Handset 9555

Motorola H24

Motorola C-Light

Motorola Phone (H24)

Motorola Phone (G24)

One Touch X200

1.2 Concurrent LAN and WiFi Communication Platforms

1.2.1 Introduction

iChip‟s new firmware, version 809, includes support for both LAN and WiFi

communication platforms in tandem. With this enhancement, iChip can support a

maximum of 4 communication platforms (and subnets) at the same time: LAN, WiFi,

Connect One


dialup/cellular modem and Host-PPP. This document describes this new functionality, the

syntax of the new associated parameters and the rules that govern its operation.

1.2.2 Current Ethernet/WiFi Rules and Operation

In firmware versions that pre-date version 809, iChip supported either an Ethernet

connection or a WiFi connection. Both of these connections were referred to as the LAN

subnet and they shared a common parameter set which described the subnet and when

relevant, the routing configuration. During iChip‟s power-up Boot process, iChip

determined if its LAN subnet is Ethernet or WiFi based on the +iLTYP parameter:

LTYP=2 … Ethernet

LTYP=1 … WiFi

LTYP=0 … Auto: WiFi if the WiFi HW exists, Ethernet otherwise.

AT+i commands that are issued to iChip and cause network activity relate to the currently

selected communication platform according to the value of the +iCPF (Communication

PlatForm) parameter:

CPF=0 … Dialup / Cellular Modem (PPP connection)

CPF=1 … LAN (Either WiFi or Ethernet)

The following AT+i parameters define iChips communication subnet:

+iDIP … Default LAN IP address. If 0.0.0.0 iChip will attempt to

negotiate with a DHCP server. Otherwise, iChip will use the

DIP value as a fixed IP. When using PPP over a modem

platform (+iCPF=0), this parameter is disregarded.

+iIPA … Current IP address. In a LAN environment (+iCPF=1) this is

the fixed address or the address assigned by the DHCP

(according to +iDIP). In a modem platform (+iCPF=0) this is

the PPP address assigned during the PPP negotiation.

+iIPG … LAN Gateway IP assigned to iChip. This parameter may

contain a preprogrammed fixed IP. However, if it contains

0.0.0.0 the gateway IP shall be assigned by the DHCP server,

if one is used (+iDIP is 0.0.0.0). Disregarded when using a

modem platform (+iCPF=0).

+iSNET … LAN Subnet Mask. May be assigned a fixed mask value. If it

is 0.0.0.0 iChip shall assume a default mask address

according to its IP category. Disregarded when using a

modem platform (+iCPF=0).

+iDNS1[p] … Primary DNS (Domain Name Server) IP. If contains 0.0.0.0

its value will be assigned by the DHCP server when using a

Connect One


LAN platform (+iCPF=1 and +iDIP=0.0.0.0) or during the

PPP negotiation when using a modem platform (+iCPF=0).

The p modifier may be „L‟ or „S‟ to designate a DNS address

for a specific platform: „L‟ is for LAN and „S‟ is for modem.

If the p modifier is omitted the current platform (as

designated by +iCPF value) is used.

+iDNS2[p] … Secondary DNS address.

1.2.3 iRouter Mode

iChip may be operated in iRouter mode. In this mode both the LAN (either Ethernet or

WiFi) and modem subnets are simultaneously active. The +iCPF parameter designates the

active communication platform. AT+i commands that instigate communication activity

shall operate on the communication subnet according to the +iCPF value. Furthermore,

parameter settings such as +iIPA, +iDNSn etc relate to the current +iCPF value. In

previous firmware versions routing services were performed between the LAN subnet and

the modem subnet such that the modem subnet was always considered to be the WAN. In

the current version a new parameter (+iWANS) selects the WAN platform. Packets

originating in the LAN subnet are always NAT‟ed before being routed to the WAN

subnet. When operating in this mode, iChip provides DHCP services to remote systems on

the LAN subnet. iChip also support a Port-Forwarding table that allows initiating access

from the WAN subnet to systems on the LAN subnet.

The following AT+i parameters govern the iRouter mode of operation:

+iARS … Auto Start Router. If ARS=0 do not auto-start router. If

ARS=1 start router automatically during the power-up

procedure. Automatically go online on the modem

communication platform.

+iDPSZ … Maximum number of concurrent systems to provide DHCP

services. If DPSZ=0 disable iChip DHCP server. The +iDIP

iChip Modem Internet

WAN

LAN Subnet

Connect One


must contain a fixed IP, above which iChip‟s DHCP server

will allocate IP addresses to requesting systems. If

+iDIP=0.0.0.0 iChip will disable its DHCP server.

+iDSLT … DHCP lease-time.

+iPFWn … Port Forwarding rules. Up to 10 Port-Forwarding rules are

available (n is in the range [0..9]).

+iWANS … WAN selector. If WANS=0 (default) the modem sub-

segment is the WAN as in previous versions. If WANS=1

The WiFi is the WAN and if WANS=2 the Ethernet is the

WAN.

1.2.4 Host PPP Mode

A host processor may be connected to iChip and send it AT+i commands. Usually a host

processor communicates with iChip over a serial communication port: Serial, USB or SPI.

The host processor may also initiate a PPP negotiation (since iChip firmware version 804)

and switch the interface protocol to PPP. In this case iChip maintains an additional IP

subnet consisting of one system (the host) which communicates with iChip over a TCP/IP

subnet. In this mode, packets from the host processor that are not directed towards iChip‟s

IP address are routed to the WAN or LAN according to the destination IP address and the

setting of the communication platform designator (+iCPF). A set of rules govern the

routing practices as follows:

IP addresses to iChip‟s IP address shall be processed by iChip

Destination IP addresses to the LAN subnet shall be routed to the LAN network with

or without NAT processing, according to the iChip‟s gateway mode. If iChip is in

gateway mode (+iIPG = +iIPA) NAT processing is not required, otherwise it is.

External destination IP address shall be routed to the platform designated in +iCPF.

The following AT+i parameters govern the Host PPP mode of operation:

+iSPPP … Start Host PPP mode. iChip negotiates a PPP connection over

the host port and automatically goes into routing mode. A

command argument designates if the modem should go

online as well.

Connect One


The Host PPP mode provides for configurations that include either the modem

communication or LAN communication platforms in addition to the PPP subnet, as well

as both LAN and modem subnets. The Port forwarding table may be defined with LAN or

modem modifiers to allow designating local ports that need to be forwarded on the LAN

subnet or the modem subnet.

1.2.5 iChip Network Services

iChip network services which are comprised of: Web server, Listen (passive) sockets and

remote AT+i socket (+iLATI), when enabled are simultaneously available on all active

subnets. For example, when iChip has all three subnets active (LAN, modem and Host

PPP) and the AT+iWWW (activate Web server) command is issued, a browser may issue

a socket open command on port 80 of iChip‟s LAN, modem or Host PPP subnet.

1.2.6 New Ethernet+WiFi mode of Operation

Firmware version 809 adds a new mode and capability to iChip. This mode allows for two

concurrent LAN communication platforms: an Ethernet subnet and a WiFi subnet. Both

these subnets will coexist and allow AT+I commands to execute communications activity

on either subnets. Furthermore, routing between any 2 subnets shall be supported.

Possible routing paths are:

EthernetModem; WiFiModem; EthernetWiFi;

Host PPPModem; Host PPPEthernet; Host PPPWiFi

To provide ample configuration for this new mode of operation several existing

parameters have been extended as well as new parameters added. Operational and routing

LAN

iChip Modem

Internet

Host

PPP

WAN

Connect One


rules have been enhanced with an attempt to remain backwards compatible with previous

versions.

The Ethernet+WiFi mode of operation is designated by a new value to the +iLTYP

parameter (4), which now has the following syntax:

LTYP=4 … Ethernet+WiFi

LTYP=3 … Reserved

LTYP=2 … Ethernet

LTYP=1 … WiFi

LTYP=0 … Auto: WiFi if the WiFi HW exists, Ethernet otherwise.

When LTYP=4 iChip shall operate in Ethernet+WiFi mode. During the power-up

procedure, iChip shall attempt to initialize both the Ethernet and WiFi subnets. At the

basic operational level, AT+i commands that activate network communications shall refer

to the +iCPF parameter, which designates which subnet to use:

CPF=0 … Dialup / Cellular Modem (PPP connection)

CPF=1 … WiFi

CPF=2 … Ethernet

Note that when LTYP does not designate Ethernet+WiFi (4) the CPF values are defined

for values of 0 or 1 only. If CPF contains 2 in this case, it is considered as 1 (i.e., LAN:

Either Ethernet or WiFi).

Assuming +iLTYP=4, the following AT+i parameters define iChips communication

subnet:

+iDIP … Default WiFi IP address. If 0.0.0.0 iChip will attempt to

negotiate with a DHCP server over the WiFi network.

Otherwise, iChip will use the DIP value as a fixed IP on the

WiFi subnet.

+iEDIP … Default Ethernet IP address. If 0.0.0.0 iChip will attempt to

negotiate with a DHCP server over the Ethernet network.

Otherwise, iChip will use the EDIP value as a fixed IP on the

Ethernet subnet.

+iIPG … WiFi Gateway IP assigned to iChip. This parameter may

contain a fixed IP. However, if it contains 0.0.0.0 the

gateway IP shall be assigned by the DHCP server on the

WiFi subnet, if one is used (+iDIP is 0.0.0.0).

+iEIPG … Ethernet Gateway IP assigned to iChip. This parameter may

contain a fixed IP. However, if it contains 0.0.0.0 the

Connect One


gateway IP shall be assigned by the DHCP server on the

Ethernet subnet, if one is used (+iEDIP is 0.0.0.0).

+iSNET … WiFi Subnet Mask. May be assigned a fixed mask value. If it

is 0.0.0.0 iChip shall assume a default mask address

according to its IP category.

+iESNT … Ethernet Subnet Mask. May be assigned a fixed mask value.

If it is 0.0.0.0 iChip shall assume a default mask address

according to its IP category.

+iIPA … Current IP address according to +iCPF. When WiFi is the

current environment (+iCPF=1) this is iChip‟s WiFi subnet

address. When Ethernet is current (+iCPF=2) this is iChip‟s

Ethernet address. When the modem is current (+iCPF=0) this

is the PPP address assigned during the PPP negotiation.

+iWIPA … Current WiFi Subnet IP Address (regardless of CPF setting).

+iEIPA … Current Ethernet Subnet IP Address

+iMIPA … Current Modem Subnet IP Address

+iHIPA … Current Host PPP Subnet IP Address

1.2.7 DHCP Server when +iLTYP=4

The DHCP server shall be activated for both the Ethernet and WiFi subnets, when

+iLTYP=4. In each case, the allocated IP addresses shall start with the next IP address

above the current IP address for the subnet upon which the DHCP request was received.

The number of allowed, concurrent systems, on each subnet shall be governed by the

value in +iDPSZ and the lease-time shall be the value stored in +iDSLT. The +iDPSZ and

+iDSLT parameters values are common values for both the Ethernet and WiFi subnets.

Therefore, if +iDPSZ=0 the DHCP server is disabled for both communication platforms.

However, note that +iDIP and +iEDIP must contain a fixed IP address for the respective

DHCP server to be enabled for that communication platform.

1.2.8 DNS Parameter when +iLTYP=4

The +iDNS1[p] and +iDNS2[p] parameter sets have been extended to the following

syntax:

For LTYP values 0, 1 and 2, the optional p attribute may be „L‟ (LAN) or „S‟ (Modem) as

on previous iChip firmware version.

For LTYP value 4 (Both Ethernet and WiFi), the optional p attribute may be „S‟

(Modem), „E‟ (Ethernet) or „W‟ (WiFi). The setting for „L‟ is disregarded in this case.

In +iDNS1 or +iDNS2 settings where the p attribute is omitted, the value of CPF is

referenced to determine which DNS parameter is affected:

Connect One


CPF=0 corresponds to „S‟

CPF=1 corresponds to „W‟

CPF=2 corresponds to „E‟

To summarize the new syntax DNS parameter in all situations see the following tables:

LTYP= 0

CPF=0 CPF=1

WiFi Exists No WiFi

DNSn - Modem DNSn - WiFi DNSn - Ethernet

DNSnL - LAN DNSnL - WiFi DNSnL - Ethernet

DNSnS -

Modem

DNSnS - Modem DNSnS - Modem

LTYP= 1

CPF=0 CPF=1

DNSn - Modem DNSn - WiFi

DNSnL - LAN DNSnL - WiFi

DNSnS -

Modem

DNSnS - Modem

LTYP= 2

CPF=0 CPF=1

DNSn - Modem DNSn - Ethernet

DNSnL - LAN DNSnL - Ethernet

DNSnS -

Modem

DNSnS - Modem

LTYP= 4

CPF=0 CPF=1 CPF=2

DNSn - Modem DNSn - WiFi DNSn - Ethernet

DNSnL - xxx DNSnL - xxx DNSnL - xxx

DNSnS -

Modem

DNSnS - Modem DNSnS – Modem

Connect One


DNSnW - WiFi DNSnW - WiFi DNSnW - WiFi

DNSnE -

Ethernet

DNSnE -

Ethernet

DNSnE - Ethernet

1.2.9 Routing Mode when +iLTYP=4

When multiple communication platforms are selected and iChip is also placed in iRouter

mode, several routing paths make themselves apparent.

IP packets originating in any of the existing sub-segments may be potentially routed to

another sub-segment. The rules governing the routing are as follows:

1. Packets originating in one of the sub-segments with iChip‟s destination IP shall be

processed by iChip‟s stack.

iChip Modem

Internet

Host

PPP

WiFi

Station

WiFi

Station

WiFi

Station

WiFi

Station

WiFi

Station

WiFi

Station

(HIPA)

(WIPA)

(MIP

A)

(EIP

A)

Connect One


2. Packets originating in one of the sub-segments to a destination IP in one of the

other iChip sub-segments shall be routed to the destination sub-segment.

3. Packets originating in one of the sub-segments to an external IP address (not one of

iChip‟s IP addresses) the packet shall be directed to the sub-segment defined in the

+iWANS parameter.

iChip maintains a NAT table for each of the sub-segments however, NAT translation does

not always take place. The rules governing when NAT translation is applied are defined as

follows:

1. Packets routed to external IP addresses on the WAN are always NAT translated.

2. Packets routed between one iChip sub-segment to another iChip sub-segment are

NAT translated if iChip is not the sub-segment gateway. Conversely, if iChip is the

sub-segment gateway, NAT translation is not used. iChip assumes it is a sub-

segment‟s gateway if iChip‟s sub-segment IP address is the same as it‟s gateway IP

address for that sub-segment. For example, if +iEIPA is the same as +iEIPG, iChip

assumes it is the Ethernet sub-segment gateway; if +iDIP has the same value as

+iIPG, iChip assumes it is the WiFi sub-segment gateway.

3. Packets routed to the modem sub-segment (over PPP) are always NAT translated.

4. Packets routed to a Host over PPP are never NAT translated.

1.2.10 The following table summarizes the routing and NAT translation rules:

Originator Src IP Dest. IP NAT Routing

Ethernet Client Internet Always WANS segment

Ethernet Client WiFi Both WiFi and Ether in

Gateway mode : No

Otherwise :

Yes

WiFi segment

Ethernet Client Host PPP No Host segment

Ethernet Client iChip IP No None. Processed in iChip

WiFi Client Internet Always WANS segment

WiFi Client Ethernet Both Ether and WiFi in

Gateway mode :

No

Otherwise :

Yes

Ether. segment

WiFi Client Host PPP No Host segment

WiFi Client iChip IP No None. Processed in iChip

Connect One


Host Internet Always WANS segment

Host Ethernet Ether in Gateway mode :

No

Otherwise :

Yes

Ether. segment

Host WiFi WiFi in Gateway mode : No

Otherwise :

Yes

WiFi segment

Host iChip IP No None. Processed in iChip

1.2.11 Example Use Case

iChip supports both Ethernet and WiFi sub-segments on the LAN end and maintains an

Internet connection using a cellular modem. It is connected to a host processor over a

serial port which issues AT+I commands. The commands are used to configure iChip

parameters and invoke Internet protocol activity on the Internet. iChip is DHCP server and

gateway on both LAN sub-segments. Routing is enabled between all sub-segments with

the cellular segment considered the WAN.

Connect One


Parameter Configuration:

Parameter Value Comment

+iLTYP 4 Enable both Ethernet and WiFi

+iDIP 10.0.0.1 WiFi Sub-segment Base Address

+iEDIP 192.168.0.1 Ethernet Sub-segment Base Address

+iDPSZ 10 Up to 10 systems on each sub-segment

+iIPG 10.0.0.1 Be Gateway on WiFi Segment

+iEIPG 192.168.0.1 Be Gateway on Ethernet Segment

+iWANS 0 Cellular segment is the WAN

+iCPF 0 AT+I commands activate IP communications

on cellular (WAN) subsegment

+iARS 1 Auto activate iRouter mode

iChip Cellular

Internet

Host

AT+i

WiFi

Station

WiFi

Station

WiFi

Station

WiFi

Station

WiFi

Station

WiFi

Station

(WIPA)

(MIP

A)

(EIP

A)

192.168.0.x

10.0.0.x

Connect One


1.3 Dynamic DNS Support

1.3.1 Introduction

Dynamic DNS (DynDNS) is a free service offered to the Internet community by a

company named “Dynamic Network Services Inc.”.

The essence of this service is to allow systems to be located on the Internet according to a

fixed host name by dynamically registering their IP address every time the IP address

changes. This is especially useful in cases where the IP address is routinely changed by

the ISP but the system needs to be approached from the Internet (it acts as a server) and it

is most convenient to use a predefined and constant symbolic name.

The facilities offered by Dynamic Network Services to support this are DynDNS servers

that allocate and manage host names in a database within their domain and accept

dynamic IP registrations per each managed host name. When a registered host is

approached from the Internet, the DynDNS server will provide the currently registered IP

address in response to a DNS inquiry for that host‟s IP address.

1.3.2 DynDNS Registration

When registered with DynDNS, a system has a host name in one of DynDNS‟ domains.

This can have the form: MyHostName.dyndns.org, for example. A host name also has an

associated password, which is assigned at the time of setting up an account with Dynamic

Network Services.

When the host needs to register its IP address, it does so by sending an HTTP request to

members.dyndns.org. The HTTP request contains the hostname, password and current IP

address. Note that the IP address registered is always the real-Internet IP address behind

which the host is connected. This is the host‟s IP address, if the host gets a public-IP (as is

normally the case when using a PSTN dial-up modem). When the host is behind a NAT or

firewall, the public IP used by the NAT/firewall is the IP that needs to be registered and

the NAT should have an associated Port-Forwarding rule to allow connection to the host.

Dynamic Network Service has a Web page that the host may refer to (using an HTTP

request), to find out the real-IP address through which it is connected. This Web page‟s

URL is: checkip.dyndns.com.

The registration process needs to be repeated if and whenever the Public-IP is changed.

This can and should be tested once in a while. Note that non-abusive use of the DynDNS

facilities requires adhering to some restrictions on the access frequency to these servers.

http://checkip.dyndns.com/

Connect One


1.3.3 iChip Interface for DynDNS

iChip exposes the following AT+I commands to the Host, so it can register and update it‟s

public IP with DynDNS as necessary:

AT+iTPIP – Used to check the Public IP and compare it with the last known Public IP

Reply - I/(<Current Public IP>),<IP changed flag>

followed by I/ONLINE or I/ERROR

Where,

<Current Public IP> is the IP returned from the checkup server

<IP changed flag > indicates the need of an IP update.

0 means our Public IP has not changed since last registration and

hence does not need updating

1 means it has changed and an update is needed.

AT+iUPIP – Used to update the Public IP with the DynDNS server if an update is

required. See AT+iTPIP command.

Reply I/(Current Public IP)<CR/LF>

followed by I/ONLINE or I/ERROR

<Current Public IP> is the public IP used to register with the DynDNS

server.

These command do not cause iChip to go online and hence are allowed only when iChip

is already online in the current network, in case an attempt to issue these command is

carried out when iChip is offline I/ERROR (067) is returned.

DynDNS Related AT+I Parameters:

DYDU - DynDNS Server URL Default: empty

HSTN - Host Name. (Existing parameter) Default: empty

HSTP - Host Name Password Default: empty

HSTU - Host User Name Default: empty

DYIP - Dynamic IP address Default: 0.0.0.0

DYIU - DynDNS IP check Server URL Default: empty

Connect One


DynDNS related errors:

I/Error 800 - DynDNS Bad server reply

I/Error 801 - DynDNS Bad ip check server reply

I/Error 802 - DynDNS Missing HSTN parameter

I/Error 803 - DynDNS Missing HSTU parameter

I/Error 804 - DynDNS Missing HSTP parameter

I/Error 805 – DynDNS Missing DYDU parameter

I/Error 806 – DynDNS Missing DYIU parameter

I/Error 807 – DynDNS not initialized

1.4 New Report: Keep-Alive Task Status

A new report (+iRP28) has been added. This report returns the current Keep-Alive PING

Task status.

When the +iTUP parameter is set to 2, and iChip goes Online via a modem, iChip will

continuously monitor its connectivity status by Pinging a preconfigured Ping server. If

iChip does not receive a reply, it will attempt to restore the Internet connection.

The new report may be used by the host to query iChip‟s Keep-Alive Ping task status. The

AT+iRP28 report command returns one of the following possible strings:

“Keep-Alive task is disabled (+iTUP is not set to 2)”

“Keep-Alive task is not active (+iPFR parameter is set to 0)”

“No PING server is defined”

“Cellular session is not active”

“PING Server is not responding”

“PING Server is Active”

1.5 New Report: Cellular Signal Quality

A new report has been added, which supports polling the cellular signal quality while the

cellular modem is online.

The new report (AT+iRP29) reports the Modem Cellular Signal Quality and the Access

Technology, in respons to the AT+CSQ command.

The reply is structured as follows:

Connect One


+iRP29 – Report the cellular signal quality (RSSI) for the modem Report Option Format

29 Returns a report of the current RSSI in the cellular network. <rssi>,<Access Technology>

I/OK

Where,

<rssi>: 0 // not available

-113 .. -51 // RSSI in dBm

<Access Techonlogy>:

Unknown // for (W)CDMA modems

GSM

Compact GSM

UTRAN

GSM with EGPRS

UTRAN with HSDPA

UTRAN with HSUPA

UTRAN with HSDPA and HSUPA

For this report to work properly, it must be enabled first in iChip with the AT+iSMSE=1

command which (as a side effect) causes the iChip to search the alternate modem interface

for processing AT commands while the modem is online. Furthermore, the alternate

interface must be supported by the cellular Modem.

Related errors:

700 - No modem is attached

701 - SMS services is not supported

736 – Read Signal Quality Failed

739 – Read Access Technology Failed

1.6 Ignore Disconnect Events in WiFi Roaming Mode

The purpose of this feature is to reduce the reconnection time when in WiFi Roaming

mode. When iChip roams from AP1 to AP2, it should stay connected to AP1 while

scanning for AP2.

From a variety of reasons, disconnect events could occur while in roaming, such as: Link

Loss if iChip stops receiving beacons from AP1 for more than 6 seconds, or if iChip

Connect One


receives Disassociate/Deauthenticate messages from AP1. When iChip disconnects it

performs a disconnection procedure, which includes closing active sockets and engaging a

DHCP session upon reconnecting.

To accommodate for these cases, without the need to perform a disconnection procedure, a

new parameter has been added (+iWLDD), which configures iChip to ignore the

disconnection if it reconnected in less than a predefined time.

Following is the new parameter syntax:

AT+iWLDD – Wireless Disconnect Delay when in roaming mode:

Syntax: AT+iWLDD=t

When in Roaming mode, WLDD defines the time delay in seconds before

actually disconnecting.

If within this time, iChip reconnects successfully, then iChip will not perform

the normal disconnection procedure.

Parameters:

t=0 feature is disabled.

t=1-255 time delay in seconds before actually disconnecting.

Default: 0 (feature disabled)

Result Code:

I/OK If t is within limits

I/ERROR Otherwise

AT+iWLDD? Reports the current value followed by I/OK.

AT+iWLDD=? Returns the message ―0-255‖ followed by I/OK.

1.7 Connect to ANY Internet Enabled AP

A new feature is added to enable connecting to any Internet-Enabled AP regardless the

current SSID list. In a previous FW version (807) the +iWIAP parameter was added to

enable a special IP-Enabled AP search procedure. When enabled, this procedure scanned

iChip‟s list of SSID in search of an AP that supports Internet access.

A new feature now allows seeking any Internet enabled AP, even if not listed in iChip‟s

SSID list.

Connect One


To configure this, if any of the SSID strings in iChip‟s SSID list (WLSI or WSIn)

contains the special constant string "$$$", than an active scan will be initiated in search of

all APs in range that have no security. iChip will then test each AP in the scan results for

an Internet-Enabled AP.

If no such Internet-Enabled APs is found in the scan results, iChip will continue scanning

and processing the SSID list cyclically.

1.8 New Behavior when setting +iWLSI or +iWLPP

A new behavior policy is now enforced when changing values to WLSI and WLPP

parameters (SSID and WPA Pass-phrase).

Previously, when changed, these parameters took immediate effect. In this version all WiFi

parameters are changed in non-volatile memory but do not take immediate effect. Changes

will take affect only after soft or cold reset or after a reconnection process due to a

disconnection event.

The purpose of this new behavior is to mairetain the current WiFi connection while

updating new WiFi parameter values.

1.9 Use Certificate’s Subject Common-Name as +iEUSN in Enterprise Mode

When negotiating an Enterprise mode WiFi connection with a RADIUS server, iChip will

use the certificate‟s Subject Common Name (CN), extracted from the certificate in its

+iCERT parameter, as the RADIUS Server login User name (+iEUSN parameter) if the

+iEUSN parameter itself is empty. In this case, iChip shall automatically configure the

+iEUSN parameter in flash with the CN value. The +iEUSN parameter can still be

reconfigured by the Host at a later time.

The modified syntax of the +iEUSN parameter is:

+iEUSN — Domain and User name for WiFi Enterprise mode

Syntax: AT+iEUSN=<username>

Sets the login user name to be used for WiFi Enterprise.

This parameter takes effect following either a hardware

or software reset (AT+iDOWN) only. A change to this

parameter during iChip operation does not affect the

current connection.

If CERT parameter is configured by the Host, and only if

+iEUSN parameter is empty, iChip shall retrieve the

Subject Common Name (CN) field from the CERT and

Connect One


shall automatically configure the +iEUSN parameter in

flash with the CN. +iEUSN parameter can still be

reconfigured by the Host at a later time.

Parameters: username = valid login username from the Server Active

Directory (AD) list.

The username should be in one of the following formats:

o username,

o username@domain,

o domain\username (for pre-windows 2000

format).

Default: Empty

Result code:

I/OK

AT+iEUSN? Report the current login User Name. If the User Name

does not exist, only <CRLF> will be returned. The reply

is followed by I/OK.

AT+iEUSN=? Returns the message 'String„. The reply is followed by

I/OK.

1.10 Proxy Server Improvements

Existing support of iChip communications via a proxy server have been enhanced. The

following changes were made:

1. A new parameter (+iPRXY) was added, to store the proxy server IP and Port.

2. DNS resolution is deferred to the proxy server itself. Previously, iChip attempted

to resolve IP addresses and then send the request through the proxy server with the

resolved IP. Following this change, iChip will not try to resolve the remote server

IP address and will route the request as-is to the proxy server leaving the DNS

resolution process to the proxy server.

Following is the full parameter syntax:

Connect One


+iPRXY — Define Proxy Server

Syntax: AT+iPRXY=”<IP>:<Port>”

Sets the IP address and port of the Proxy to use for all

subsequent socket communications.

Parameters:

<IP>:<Port> IP has the format x.x.x.x

Port is 0..65535

Default: Empty (Do not use a Proxy server)

Result Code:

I/OK If parameter is a single string

I/ERROR Otherwise

AT+iPRXY? Returns the current PRXY value followed by I/OK.

AT+iPRXY=? Returns the message “string‖ followed by I/OK.

1.11 Send and Receive SMS Messages

iChip now supports a new set of AT+I commands that may be used to send and receive

SMS messages over a cellular modem, while the modem is online in data mode. While

online, SMS messages are managed through a USB cellular modem‟s alternate interface.

In this firmware version if iChip is connected to a USB cellular modem, it attempts to

locate the alternate interface. Naturally, the connected cellular modem must support an

alternate interface for one to be found and utilized.

A new parameter (+iSMSE) may be used to Enable or Disable SMS management. This

parameter defaults to Disabled (=0), therefore, in order to enable SMS capabilities it must

be first set to 1.

Following is the full parameter syntax:

+iSMSE — Enable/Disable SMS Function

Syntax: AT+iSMSE=<n>

Defines whether SMS functionality is enabled and which

mode is supported.

Parameters: n = 0-1

n=0 Disable SMS

n=1 Enable SMS in TEXT mode

Default: 0 (SMS disable)

Result code:

Connect One


I/OK If n is a legal value.

I/ERROR Otherwise

AT+iSMSE? Returns the current SMSE value followed by I/OK.

AT+iSMSE=? Returns the message ―0-1‖ followed by I/OK.

When SMS services are enabled, the following commands may be used to send, receive or

delete SMS messages:

+iSSMS — Send SMS Message

Syntax: AT+iSSMS:<mf>,<rn>,<data>

Sends the ASCII data to the recipient cellular number in

the required SMS format

Parameters:

<mf> The SMS message format

<rn> The recipient‟s cellular number (ASCII string)

<data> An ASCII bytes stream to be sent to the specified

recipient.

Command Options:

<mf> The message format can be either PDU (0) or TEXT (1).

Note: Only SMS in TEXT format is supported in his

version.

<rn> An 8-bit byte stream composed from printable characters

only. The recipient number length is limited to 16

characters.

<data> An 8-bit byte stream composed from ASCII characters

only. The data length is limited to 192 characters.

Result code:

I/OK When command is received and about to be processed.

Followed by:

-or-

I/ONLINE After terminating the connection on the dialup/cellular

side when iChip goes off-line (CPF=0).

-or-

I/ERROR Otherwise

Connect One


+iRSMS — Retrieve SMS Message

Syntax: AT+iRSMS

Retrieve a pending SMS message from the modem

storage.

Result code: <index>, <sender>, <time>, <body><EOT>

Followed by:

I/OK End of the transaction.

A new report allows retrieving ALL pending SMS messages at once:

+iRP31 – Display all Pending SMS Message Report Option Format

31 Returns all pending SMS messages from the modem storage. In the format:

<index>, <sender>, <time>, <body> <EOT>

Followed by:

I/OK

+iDSMS — Delete SMS Message

Syntax: AT+iDSMS:<index>

Delete a pending SMS message from the modem storage.

Result code: I/OK

Or

I/ERROR

The existing +iRP7 report, which notifies the host when data from the network is available,

has been extended to report on available SMS messages as well. Bit #11 set to „1„ indicates

that the cellular modem contains at least one buffered SMS message, which needs to be

read (received) by the host.

Connect One


The full syntax of the extended +iRP7 report is:

+iRP7 – Report Option

Format

7 I/xxxx xxxx – 16 bit Hex Value Bitmap A bit set to ‘1‘ indicates that the corresponding socket contains buffered data, which needs to be read by the host.

bit 15 11 10 7 0 socket SMS WEB 9 8 7 6 5 4 3 2 1 0

Bit 11 is set to ‘1‘, when one or more incoming SMS messages are stored and pending in the modem storage. It will be reset to ‘0‘ when the host reads all the pending messages, using the AT+iRSMS or AT+iRP31 commands.

New SMS related Error codes have been added: 700 Modem is not attached

701 SMS services is not enabled

702 The SMS message format must be 0 (for PDU) or 1 (for TEXT) only

703 The recipient cellular number is empty

704 The message parameter is empty

705 The recipient cellular number is too long (> 32)

706 The message string is too long (> 192)

707 Set SMS message’s format failed (AT+CMGF returns ERROR)

708 Set SMS Service Center Address failed (AT+CSCA returns ERROR)

709 Set SMS recipient failed (AT+CMGS returns ERROR)

710 SMS data was rejected (ERROR returns after CTRL-Z)

711 SMS transmission failed (AT+CMGS returns ERROR)

712 Delete SMS message failed (AT+CMGD returns ERROR)

713 List SMS messages failed (AT+CMGL="ALL" returns ERROR)

714 Mobile equipment (ME) failure

715 SMS service of mobile equipment (ME) is reserved.

716 The operation to be done by the AT command is not allowed.

717 The operation to be done by the AT command is not supported.

718 One or more parameter values assigned to the AT command are

invalid. (For PDU mode)

719 One or more parameter values assigned to the AT command are

invalid. (For Text mode)

720 There is no SIM card.

721 The SIM card requires a PIN to operate. The AT command +CPIN can be

used to send the PIN to the SIM card.

722 The SIM card requires a PH SIM PIN to operate. The AT command +CPIN

can be used to send the PH SIM PIN to the SIM card.

723 SIM card failure.

724 The SIM card is busy.

725 The SIM card is wrong.

726 The SIM card requires a PUK to operate. The AT command +CPIN can be

used to send the PUK to the SIM card.

727 Memory/message storage failure.

728 The memory/message storage index assigned to the AT command is

invalid.

729 The memory/message storage is out of space.

730 The SMS center (SMSC) address is unknown.

731 No network service is available.

Connect One


732 Network timeout occurred.

733 There is no need to send message acknowledgement by the AT command

+CNMA.

734 An unknown error occurred.

735 The modem does not respond

736 Signal Quality request failed (AT+CSQ returns ERROR)

737 Illegal SMS message index

1.12 SSL Server Listen Socket

1.12.1 Introduction

Currently, iChip supports a single SSL Client Socket or an HTTPS server. Only one active

SSL socket is enabled at any time due to memory restrictions.

A new feature in this version adds the capability to open an SSL Listen socket and

therefore act as SSL Server. The following restrictions apply:

Only one SSL Listen socket can be opened.

The SSL Listen socket backlog is fixed to 1.

SSL Listen Socket may be opened only if the +iCERT and +iPKEY parameters are

configured (non-empty).

+iCERT and +iPKEY shall contain the SSL Server certificate (signed by a CA) and Server

private key. +iCERT shall be sent to the remote SSL client during the SSL HS (server hello

transaction).

If the option to request Client Authentication is selected, the +iCA parameter must contain

the CA certificate to verify the Client Certificate.

Concurrent SSL Socket Restrictions

iChip memory limitations limit the use of concurrent active SSL sockets, Listen SSL

sockets and HTTPS server:

When an SSL client socket is Active, the HTTPS server can be enabled

(AT+iwww=100), however, a remote HTTPS client will not be able to connect.

When the HTTPS server is enabled, an SSL client socket can be activated only if a

remote client is not connected.

Only one SSL Server listen socket can be opened concurrently including HTTPS:

o If HTTPS is enabled (at+iWWW:100), opening an SSL listen socket will fail.

o If an SSL Listen socket is opened, enabling HTTPS will fail.

When an SSL socket is active – an SSL listen socket can be enabled but a remote

client will not be able to connect.

When an SSL listen socket is enabled, an SSL active socket can be connected only if

a remote client is not currently connected.

A new command (AT+iLSSL) has been added to open an SSL Listen socket. Following is

the full syntax of the new command:

Connect One


AT+iLSSL – Open an SSL Listen Socket

Syntax: AT+iLSSL:<port> , <backlog>, <clientAuth>

Opens an SSL Server listen socket on a local IP address and the

specified port <port>. The <backlog> parameter specifies the

maximum number of remote concurrent connections allowed

through the listening socket (currently backlog is fixed to 1). The

<clientAuth> parameter specifies whether Client Authenticated is

required by the SSL Server.

Parameters:

<port> 0 - 65535.

<backlog> 1 - 10

<clientAuth> 0 - 1

Command Options:

<port> Listen port to be used by a remote system when connecting to iChip.

<backlog> Specifies maximum number of active connections that may be

concurrently established through the listening socket.

Currently, backlog must be 1.

<clientAuth> Specifies whether Client Authentication is required. If clientAuth=1, the

SSL Server requests client authentication.

Result Code:

I/<sock handle>

Upon successfully opening an SSL Server listening socket, a socket

handle is returned. The socket handle <sock handle> is in the range

10..11 and used to reference the socket in all following socket

commands

I/ERROR 225

If SSL Server listen socket is already opened or if HTTPS was

activated (at+iWWW:100)

I/ERROR Otherwise

Connect One


1.13 Wakeup on SMS

A new method for triggering iChip to go Online has been added. This method is based on

receiving a qualifying SMS message and going online in response. The SMS message

may contain the address of a registration server to override the +iRRSV parameter, in

which case iChip will register with the specified server when going online.

The new method is configured by setting the +iTUP parameter to the new value 3.

Following is the modified syntax:

+iTUP –

New Command Option: 3:

Enter triggered Internet session initiation mode. Upon receiving a hardware signal trigger

(MDSEL signal pulled low) or a specific SMS message, establish a PPP Internet

connection and carry out the IP registration process according to the relevant registration

option parameters.

If any characters are received on the host port prior to receiving a hardware signal, iChip

exits this mode and functions normally. In this case, to reinstate this mode, issue

AT+iTUP=3 again; Reset iChip by issuing the AT+iDOWN command, or recycle power.

The wakeup SMS must adhere to the following specific syntax:

COWAKEUP[,Registration Server:Port]

If the optional Registration Server:Port field is present it overrides the current +iRRSV

parameter value.

1.14 Controlling the VBUS signal

1.14.1 Introduction

The Universal Serial Bus (USB) transfers power on a signal named VBUS. This power is

generated by the downstream facing port (host) and is supplied on pin 1 of the USB

connector. VBUS is nominally +5V referenced to the GND signal (pin 4) of the USB

connector, and is capable of sourcing up to 500 mA.

Every USB device must detect the VBUS signal on the USB connector as a way to

determine connection/disconnection with a host.

1.14.2 iChip VBUS Control

A new parameter (+iVBUS) has been added to allow configuration of an iChip GPIO as the

Vbus enabler. When configured, iChip shall clear this signal upon disabling the USB host

(VBUS OFF), and shall set it one second after initialization of the USB host port (VBUS ON).

Note:

Connect One


The USB Host is disabled upon startup (HW or SW startup), and upon exiting auto-

detection mode without selecting the UHP as the host interface or the modem

interface (iMIF).

The USB Host is enabled when entering auto-detection host mode, and when the

UHP is used as the modem interface or as the host interface. I.e. iHIF or iMIF are

set to UHP (5).

The +iVBUS parameter has the following syntax:

+iVBUS — VBUS GPIO

Syntax: AT+iVBUS=<val>

Define which iChip PIOC general-purpose I/O pin (GPIO) will be used as the

VBUS enable signal

Parameters:

val=0 VBUS signal is disabled.

val=1-6 Pin 0-5 of PIOC (general-purpose I/O pins group C) will be used

as iChip‟s VBUS enable signal.

Default: 0 (VBUS signal disabled)

Result Code:

I/OK If pin is within limits

I/ERROR Otherwise

AT+iVBUS? Reports the current value followed by I/OK.

AT+iVBUS=? Returns the message ―0-6‖ followed by I/OK.

Note:

The setting will take effect only after a SW or HW reset.

Connect One


1.15 New MTYP value for GSM Modem TC65i

A new +iMTYP value (13) has been added to support the TC65i GSM cellular modem,

which requires a prolonged startup time after reset.

This +iMTYP value is equivalent to the normal GSM modem (+iMTYP=2) with the

distinction that iChip shall delay for 2 seconds before sending the first AT command to

the modem.

1.16 New CPIN Parameter

A new parameter, +iCPIN has been added to allow configuring a Personal Identification

pass-phrase if one is required by the Telco to authenticate the cellular modem connection.

The syntax of the new parameter is:

+iCPIN — Cellular PIN (personal identification number)

Syntax: AT+iCPIN=<pin>

Store the SIM PIN1 to register to the GSM network.

A personal identification number (PIN, pronounced

"pin") is a secret numeric password shared between a

user and a system that can be used to authenticate the

user to the system.

Parameters: pin = password (string type)

Default: NULL

Result code:

I/OK

I/ERROR Otherwise

AT+iCPIN? Returns an alphanumeric string including the password.

The reply is followed by I/OK.

AT+iCPIN=? Returns the message 'String' followed by I/OK.

1.17 Additional Direct-Modem AT+I commands

Support for additional AT+I commands that need to be sent directly to the modem in

transparent mode has been added.

The direct-modem AT+I commands that will now be transparently sent (as AT

commands) to the modem are:

+ICF (TE-TA Character framing)

http://en.wikipedia.org/wiki/Password

Connect One


<format>:

0- 8 data, 2 stop, no parity

1- 8 data, 1 stop, 1 parity

2- 8 data, 1 stop, no parity (default)




<parity>

0- odd

1- even

2- mark (bit is always 1)

3- space (default) bit is always 0

AT+IFC (TE-TA local flow control)

<DCE by DTE>

0- NONE

1- Xon/Xoff (not supported)

2- RTS

<DTE by DCE>

0- NONE


2- CTS

+ICF (TE-TA Character framing)

<format>



2- 8 data, 1 stop, no parity (default)




<parity>

0- odd

1- even

2- mark (bit is always 1)

3- space (default) bit is always 0

AT+IFC (TE-TA local flow control)

<DCE by DTE>

0- NONE


2- RTS

Connect One


<DTE by DCE>

0- NONE


2- CTS

Connect One


2 Limitations Solved

Reference Description

Connect One


3 Known Limitations in 809B01

Ref. Description

General

Connect One


4 Supported Platforms

iChip OS i2128D809B01 supports the platforms listed below.

Type Model Comments

iChip CO2128, CO2144

Embedded Device Server Secure Socket iWiFi

Embedded Device Server mini Socket iWiFi

Embedded Device Server Nano WiReach

Embedded Device Server Nano LANReach

Embedded Device Server Nano Socket iWiFi

Embedded Device Server Nano Socket LAN

External Device Server Secure iLAN

External Device Server Secure iWiFi

WiReach Classic

Nano WiReach SMT

5 Firmware File Information

The following table includes detailed information that can be used to verify the integrity

of the downloaded firmware.

809B01 File Name File Size (bytes)

MD5 Checksum

IMF (Local firmware update)

i2128d809B01.imf 679,208 2b898be5a6b419f4595433f059cdaf8d

IMZ (Remote firmware update)

Note: Only for 2Mb Flash

i2128d809B01.imz 437,069 0ad9337c9f50b69b53590b0db497a2c9

tel: +972-9-766-0456 fax: +972-9-766-0461 release notes · qualcomm 3g cdma icon 225 huawei ec1260...

Documents