Beijer Electronics (formerly QSI Corporation)

Manufacturer of Mobile Data and Human Machine Interface Terminals.
It is currently Mon Nov 20, 2017 2:25 am

All times are UTC - 7 hours




Post new topic Reply to topic  [ 10 posts ] 
Author Message
PostPosted: Thu May 17, 2012 7:22 am 
Offline

Joined: Thu Jan 11, 2007 1:21 am
Posts: 11
Hi Guys

I am trying to establish a PPP connection over the serial port with 1 of our "older" devices. Ultimately the purpose of this is to do FTP transfers over the serial port.

I know for a fact that our device handles PPP connections correctly, because we have PC-based applications which succeeds in this.

However, when I try to initiate a PPP connection using the PPPCommV2 object, it seems that the PPP negotiation is unsuccessful.

I have decoded the packet transfer and it looks like the authentication fails right after the G55 presents the username (test) and password (pass) to the device. We have very specific requirements in this regards.

Question #1: Is there a way I can set the username and password for PPP authentication?

Also, I see in your help file the following wrt the PPPCommsV2 object: "You will need a terminal to test PPP. PPP does not work in Simulation View of Qlarity Foundry."

Question #2: Why is the testing of PPP not supported in simulation mode. Is there any way this can be included?

Regards

Dolf

_________________
Rudolph van Niekerk

\o

@\ Fight Gravity

< \ Climb


Top
 Profile  
 
PostPosted: Thu May 17, 2012 6:34 pm 
Offline
QSI Support
QSI Support
User avatar

Joined: Wed Mar 08, 2006 12:25 pm
Posts: 881
Location: Salt Lake City, Utah
I can answer the 2nd question quite easily. Simulation View doesn't support PPP because to do so would essentially involve hooking the API function and routing it to the Windows PPP functions. This is quite doable, but a fair amount of work for a feature that receives relatively little use. Additionally it wouldn't really solve your problem, because all it would prove is that Windows PPP supports your device, which isn't the problem you are facing.

The first question is a bit trickier. All Qlarity supports is basic PPP (establishing a network connection via the serial port). I don't believe it supports CHAP or any of the higher level protocols that are used to establish an authenticated PPP session, although I can double check that when I get back to the office tomorrow. This would explain why the PPPCommV2 object doesn't support a username and password.

_________________
Jeremy
http://www.beijerinc.com


Top
 Profile  
 
PostPosted: Fri May 18, 2012 12:30 am 
Offline

Joined: Thu Jan 11, 2007 1:21 am
Posts: 11
Hi Jeremy

Thanks. Okay, I understand.... awaiting your response on the PPP question.

Regarding the "basic PPP": I am more than willing to implement the additional features for PPP if I am the only G55 user who will be using it (which I think may very well be the case). I would just need some guidance from your side as to how and where to implement these.

Otherwise, if this is not feasible I will end up building my own PPP object using the serial port anyway. However, I would like to use the PPPControl() features provided by the API.... and those are completely hidden from me?

Regards

_________________
Rudolph van Niekerk

\o

@\ Fight Gravity

< \ Climb


Top
 Profile  
 
PostPosted: Fri May 18, 2012 12:47 am 
Offline

Joined: Thu Jan 11, 2007 1:21 am
Posts: 11
Sorry, I'd like to comment on your statement: "Additionally it wouldn't really solve your problem, because all it would prove is that Windows PPP supports your device, which isn't the problem you are facing."

I disagree... it would save a fair amount of hassle and time if I can test my implementation through the simulation G55 to our device, without the need to download the program to my G55 terminal after every change.
Additionally I have the visibility of breakpoints and debug prints in the simulation view.

Regards.

_________________
Rudolph van Niekerk

\o

@\ Fight Gravity

< \ Climb


Top
 Profile  
 
PostPosted: Fri May 18, 2012 6:59 am 
Offline
QSI Support
QSI Support
User avatar

Joined: Wed Mar 08, 2006 12:25 pm
Posts: 881
Location: Salt Lake City, Utah
I thought you were trying to debug your PPP connection, for which substituting Windows PPP drivers wouldn't provide a lot of use.

General application debugging in simulation view should be possible. Here is how I might approach things: Use Windows to establish a PPP connection with the remote devices. In your PPPCommV2 object, add the following code:

#if _tool_sim
init connectatstartup := false
init autoreconnect := false
#else
init connectatstartup := true
init autoreconnect := true
#endif

Next, tell Qlarity Foundry not to attach the simulated G55 serial port to a real serial port (Tools->Settings->Simulation).

Depending on the IP address settings of your PPP connection and any other network adapters, you may also need to tell Qlarity Foundry to use your PPP adapter as the simulated adapter. In that case, start the PPP connection, then restart Qlarity Foundry and go to the Simulation Settings and select the correct network adapter as the Ethernet simulation adapter.

Now, any network code in your Qlarity application will use the externally established PPP connection for communication.

_________________
Jeremy
http://www.beijerinc.com


Top
 Profile  
 
PostPosted: Fri May 18, 2012 7:17 am 
Offline
QSI Support
QSI Support
User avatar

Joined: Wed Mar 08, 2006 12:25 pm
Posts: 881
Location: Salt Lake City, Utah
I did double check, Qlarity only handles the lower level PPP protocols. You can read more details about that under the PPPControl API function's documentation, which I have pasted here for conveneience

Quote:
PPPControl
Location: Library standard native api_defs

func PPPControl(startobj as objref, enable as boolean)

Parameters:
startobj: The object registering for the message.
enable: A boolean value indicating if PPP should be enabled (true) or disabled (false)



Enable (attempt to establish) or Disable (terminate) a PPP connection. Executing this function with the enable parameter set to TRUE will begin the process required to establish a PPP connection (i.e. an LCP configure request is sent on the serial port specified as the PPP_PORT by the SetPPPConfig function). Establishing a PPP connection is a negotiation process between two peers. This process will proceed automatically from LCP to IPCP and when completed sucessfully (i.e. IPCP reaches the opened state) will generate the message MSG_PPP_NEGOTIATED. If after retries the negotiation process is unable to complete successfully, a MSG_PPP_STOPPED message will be generated.

Executing this function with the enable parameter set to FALSE will begin the process required to terminate a PPP connection (i.e. an IPCP terminate request will be sent to the peer). The termination process will proceed automatically from IPCP to LCP and when the terminal has received the LCP terminate acknowledge message from the peer, the MSG_PPP_STOPPED message will be generated. The MSG_PPP_STOPPED message will always be generated, even if the peer stops responding, however, it may be delayed due to retries in that case.

NOTES:
An exception will be generated if an attempt is made to open an already opened connection. An exception willl also be generated if an attempt is made to close a connection when no connection has been established. Since this is a peer to peer protocol there is an interesting case that can occur. The peer device may terminate the connection (by not responding or by actively closing using an LCP terminate request). In that case a MSG_PPP_STOPPED message will be generated but the connection is not fully closed. It is still required to call this function with the enable set to false before an attempt can be made to reestablish a connection. In this 'half opened' case, a second MSG_PPP_STOPPED message will be generated (the first occured when the peer closed the connect) when this function is called with the parameter set to FALSE.

The comport used for PPP communications cannot be used for other communications once the PPPControl function has been called with the enable parameter set to TRUE until the PPP connection is terminated by calling PPPControl with the enable parameter set to FALSE. Once in ppp mode, any attempt to send information on the PPP comport using the normal comsend functions (comsend or transmit) will generate an exception. After the PPP connection is terminated (by executing PPPControl with the enable parameter set to false), the comport can once again be used as a general purpose comport.

When terminating a PPP connection, no attempt is made to gracefully close open network connections (TCP/IP, UDP). Therefore, prior to calling PPPControl with the enable parameter set to false you should call netclose for all open network connections and wait for them to terminate.

PPP connections and Ethernet connections are mutually exclusive.


Note that there is no provision for specifying a password, or mention of CHAP or other authentication layers.

_________________
Jeremy
http://www.beijerinc.com


Top
 Profile  
 
PostPosted: Mon May 21, 2012 1:38 am 
Offline

Joined: Thu Jan 11, 2007 1:21 am
Posts: 11
Hi Jeremy

1) I would actually clear up a misunderstanding we're having: I would actually like to debug the PPP connection when made over the serial port in simulation view, i.e. in simulation view, set the "G55" COM port to a real COM port on my PC and then connect that to my external device's serial port.

2) I know I am asking a lot now, but is it possible to provide me with the underlying source code of your PPPControl(), SetPPPConfig() and GetPPPConfig() API functions. The reason for me asking is thus:
I am at the point of building my own object to handle the PPP connection over the serial port anyway. However, since a lot of the work has already been done on your side, it feels like re-inventing the wheel to some extent. I have a few specific requirements (like being able to configure the username and password, which is already present in you PAP transaction) and I would rather prefer to extend the existing PPP connection configuration (possibly with SetPPPConfig()) rather than building the entire stack from scratch.

I am planning to implement the PPP connection according to the following Application Note: "Connecting an M68HC08 Family Microcontroller to an Internet Service Provider (ISP) using the Point-To-Point (PPP) protocol" http://cache.freescale.com/files/microcontrollers/doc/app_note/AN2120.pdf.
I've had success on several different devices using this App Note.

Please advise?

Regards.

_________________
Rudolph van Niekerk

\o

@\ Fight Gravity

< \ Climb


Top
 Profile  
 
PostPosted: Mon May 21, 2012 6:47 am 
Offline
QSI Support
QSI Support
User avatar

Joined: Wed Mar 08, 2006 12:25 pm
Posts: 881
Location: Salt Lake City, Utah
DikGatDolf wrote:
Hi Jeremy

1) I would actually clear up a misunderstanding we're having: I would actually like to debug the PPP connection when made over the serial port in simulation view, i.e. in simulation view, set the "G55" COM port to a real COM port on my PC and then connect that to my external device's serial port.


I think I understand your point now. Let me clear up a couple of things as well, so you understand exactly why the scenario you ask is not available.

When it came to implementing PPP simulation we were faced with three approaches. Each of these approaches has significant drawbacks.

#1: Hook up Qlarity Foundry to the Windows PPP API functions. This is probably the most straightforward approach, although not everyone has the PPP support installed. As you point out it doesn't really help your situation as it doesn't really let you debug how the connection is established and has a number of differences from how things would run on the unit. It does allow debugging of Qlarity code that makes use of the already established connection.

#2: Use the G55 firmware code, including the full network stack. First of all this is a lot of work. We don't use the native G55 network stack anywhere else in Qlarity Foundry. The networking stack we use was never intended to run under Windows, but rather on embedded OSes. It also means tooling Qlarity Foundry to use a different network stack depending on whether PPP or Ethernet are being simulated. Also, distributing the G55 network stack in Qlarity Foundry raises licensing concerns, especially where we do not charge for Qlarity Foundry.

#3: Use the G55 firmware PPP code, but tool it against the Windows networking stack. This is extremely complicated and requires us to essentially write a network adapter device driver for Windows.

If we were to attempt any of these options in Qlarity Foundry, it would likely be the first one. The main reason why we have not added PPP support to Simulation View, is that it is something that very few people are using. We originally added it for one specific customer and added enough to meet their needs. Since it could be useful to more we exposed the APIs publicly.

Quote:
2) I know I am asking a lot now, but is it possible to provide me with the underlying source code of your PPPControl(), SetPPPConfig() and GetPPPConfig() API functions. The reason for me asking is thus:
I am at the point of building my own object to handle the PPP connection over the serial port anyway. However, since a lot of the work has already been done on your side, it feels like re-inventing the wheel to some extent. I have a few specific requirements (like being able to configure the username and password, which is already present in you PAP transaction) and I would rather prefer to extend the existing PPP connection configuration (possibly with SetPPPConfig()) rather than building the entire stack from scratch.

I am planning to implement the PPP connection according to the following Application Note: "Connecting an M68HC08 Family Microcontroller to an Internet Service Provider (ISP) using the Point-To-Point (PPP) protocol" http://cache.freescale.com/files/microcontrollers/doc/app_note/AN2120.pdf.
I've had success on several different devices using this App Note.


I want you to be fully aware of what you are asking here. All native Qlarity APIs, including the three you mention, are part of the native Qlarity kernel, which is implemented in C. In order to modify or extend any of them you would need the complete kernel source code and build environment. This is not something that we have generally been willing to distribute.

Alternatively you could ask us to add the support for you. This would likely entail a custom engineering fee.

I would strongly suggest contacting your sales representative to discuss either option.

_________________
Jeremy
http://www.beijerinc.com


Top
 Profile  
 
PostPosted: Mon May 21, 2012 8:28 am 
Offline

Joined: Thu Jan 11, 2007 1:21 am
Posts: 11
Re:
Quote:
I want you to be fully aware of what you are asking here.


Yes, I fully understand... that is why said "I know I am asking a lot now". I thought maybe that it your API is a modular design and I could extend the PPP related functionality for you (for free :wink: )

Being in the software business myself I understand the risks involved with this kind of IP, so I am not at all surprised that you would not be willing to share this.

I have already started building my own PPP object (With the lowest level derived from BasicSerialV2), and it looks promising, so I think I will go this route.

Thanks all the same :D

Regards.

_________________
Rudolph van Niekerk

\o

@\ Fight Gravity

< \ Climb


Top
 Profile  
 
PostPosted: Mon May 21, 2012 9:20 am 
Offline
QSI Support
QSI Support
User avatar

Joined: Wed Mar 08, 2006 12:25 pm
Posts: 881
Location: Salt Lake City, Utah
A modular API solution is something that we have wanted to do for a number of years. Back when Qlarity was originally authored, dynamic code loading was not very common for the types of microcontrollers we were using at the time.

_________________
Jeremy
http://www.beijerinc.com


Top
 Profile  
 
Display posts from previous:  Sort by  
Post new topic Reply to topic  [ 10 posts ] 

All times are UTC - 7 hours


You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot post attachments in this forum

Search for:
Jump to:  
cron
Powered by phpBB® Forum Software © phpBB Group