I need to create a PPP connection over a serial port between an embedded device running Windows CE 6 and a PC running Windows 7.
I've configured a dial-up modem on Windows 7 according to this: https://stackoverflow.com/a/7085259/512910
I used a terminal app on the CE device to confirm that attempting a connection sends the string "CLIENT".
I've also created a direct connection interface on the CE device, and used a terminal app to confirm that attempting a connection also sends the string "CLIENT" to the Windows 7 machine.
Unfortunately, neither side actually responds, and I'm not sure what the problem is.
What am I missing here? Is there a way to make either side listen for an incoming connection?
-------------------------------- Edit 1/12/12 ----------------------------------
I needed to add an incoming connection on the Windows 7 side. However, the connection doesn't appear to work, and times out after 90 seconds.
Here is my modem log.
01-09-2012 19:06:29.542 - Recv: CLIENT
01-09-2012 19:06:29.542 - Interpreted response: Ring
01-09-2012 19:06:29.542 - TSP Completing Async Operation(0x00010227) Status 0x00000000
01-09-2012 19:06:29.542 - TSP(0000): LINEEVENT: LINEDEVSTATE_RINGING(0x1)
01-09-2012 19:06:29.542 - TSP(0000): Answering Call
01-09-2012 19:06:29.542 - Answering the call.
01-09-2012 19:06:29.557 - Send: CLIENTSERVER
01-09-2012 19:06:29.557 - Connection established at 115200bps.
01-09-2012 19:06:29.557 - Error-control off or unknown.
01-09-2012 19:06:29.557 - Data compression off or unknown.
01-09-2012 19:06:29.557 - TSP Completing Async Operation(0x0001029e) Status 0x00000000
01-09-2012 19:06:29.557 - TSP(0000): LINEEVENT: LINECALLSTATE_CONNECTED
01-09-2012 19:06:59.572 - Read: Total: 388, Per/Sec: 12, Written: Total: 12, Per/Sec: 0
01-09-2012 19:08:30.208 - TSP(0000): Dropping Call
01-09-2012 19:08:30.208 - Hanging up the modem.
01-09-2012 19:08:30.208 - Hardware hangup by lowering DTR.
01-09-2012 19:08:30.208 - 115200,8,N,1, ctsfl=1, rtsctl=2
01-09-2012 19:08:30.208 - Initializing modem.
01-09-2012 19:08:30.208 - Waiting for a call.
01-09-2012 19:08:30.208 - TSP(0000): LINEEVENT: LINECALLSTATE_DISCONNECTED(0x1)
01-09-2012 19:08:30.208 - TSP(0000): LINEEVENT: LINECALLSTATE_IDLE
01-09-2012 19:08:30.208 - TSP Completing Async Operation(0x0001027c) Status 0x00000000
01-09-2012 19:08:30.208 - TSP(0000): Dropping Call
01-09-2012 19:08:30.208 - TSP Completing Async Operation(0x000101e3) Status 0x00000000
01-09-2012 19:08:30.208 - TSP(0000): Closing Call
Here's a troubleshooting list I created back in 2002, but it should still be valid (#8 is likely not applicable, and some menus may have changed):
Make sure your cable is truly null modem. Your null modem cable must also be fully connected (CTS, RTS, DTR, DSR).
Click the ActiveSync icon on your PC and select Get Connected from the File menu. It should be actively scanning for your device when you run REPLLOG (the timing of getting both systems searching for each other is sometimes important).
Reset the CE device and follow the instructions from the beginning.
If REPLLOG doesn't connect within a few seconds of being run, tap the CANCEL button and retry.
If you get the "Verify COM Port Availability" dialog shortly after telling ActiveSync to Get Connected, you may not be connected to the right port of the CE device, or your cable may have a problem.
You can test the serial connection to your desktop PC by shutting down ActiveSync and running Hyperterminal at 19200,8N1. When you run REPLLOG, you should see "CLIENT" appear in the Hypterterminal window each of the four times the CE device tries to connect.
Verify that your device supports DTR or you have it shunted in the cable. PC ActiveSync application looks at DTR to determine if a device is connected.
A bug in some releases of CE reduce the number of chances you have to get connected. Consider loading a build created in June 2001 or later that adds DataSync components from Microsoft.
Make sure that ActiveSync has the communication protocol you are trying enabled. For example, if you are connecting with a null modem serail cable, make sure that ActiveSync has serial communications enabled. These settings are available through the ActiveSync interface under File | Connection Settings...
Related
Our software (Nmap port scanner) needs to quickly determine the status of a non-blocking TCP socket connect(). We use select() to monitor a lot of sockets, and Windows is good at notifying us when one succeeds. But if the port is closed and the target sends a TCP RST, Windows will keep trying a few times before notifying the exceptfds, and the socket error is WSAECONNREFUSED as expected. Our application has its own timeout, though, and will usually mark the connection as timed-out before Windows gives up. We want to get as close as possible to the behavior of Linux, which is to notify with ECONNREFUSED immediately upon receipt of the first RST.
We have tried using the TCP_MAXRT socket option, and this works to get select() to signal us right away, but the result (for closed ports) is always WSAETIMEDOUT, which makes it impossible to distinguish closed (RST) from filtered/firewalled (network timeout), which puts us back at the original problem. Determining this distinction is a core feature of our application.
So what is the best way on Windows to find out if a non-blocking socket connect() has received a connection reset?
EDITED TO ADD: A core problem here is this line from Microsoft's documentation on the SO_ERROR socket option: "This per-socket error code is not always immediately set." If it were immediately set, we could check for it prior to the connect timeout.
Im trying to open a L2Cap HID Channel And Interrupt channel so I can send HID commands to a bluetooth device.
I've done all my service advertising and device paring and established a baseband connection.
The Hid Control channel opens fine.
When I try to create my kBluetoothL2CAPPSMHIDInterrupt connection
l2capChannelQueueSpaceAvailable
delegate method called (not sure what this means) followed by
l2capChannelOpenComplete
but the connection closes immediately calling
l2capChannelClosed
How can I correctly open these connection?
I've spent a long time digging through the IOBlueTooth framework and the bluetooth.org HID spec but theres barely any helpful information (that I can find at least).
When i trace out my L2Cap channels I see some null values for
mIncomingDataListener
and
mEventDataListener
. I dont know how to set these or if they have anything to do with my problem.... just speculating.
The code snippet below is my attempt so far to make the connections after a connection to the device has been established.
-(void)establishL2CappConnections:(IOBluetoothDevice*)device
{
IOReturn r;
IOBluetoothL2CAPChannel *ch1;
r = [device openL2CAPChannelSync:&ch1
withPSM:(BluetoothL2CAPPSM)kBluetoothL2CAPPSMHIDControl
delegate:self];
self.mL2CappChannel=ch1;
NSLog(#"r == %i",r);
IOBluetoothL2CAPChannel *ch2;
r = [device openL2CAPChannelSync:&ch2
withPSM:(BluetoothL2CAPPSM)kBluetoothL2CAPPSMHIDInterrupt
delegate:self];
self.mL2CappInterruptChannel=ch2;
NSLog(#"r == %i",r);
}
Edit:1
I've attached my packet logs. It's strange, a request for
kBluetoothL2CAPPSMSDP 0x0001
gets made without me requesting it and then everything starts disconnecting.
BT Packet Logs
As per your logs its very clear that your device in in Limited Connection mode, its stays Active for 30sec or less. change device settings to make it General Discoverable.
kBluetoothL2CAPPSMSDP 0x0001
means Bit 13 - Limited Discoverable Mode
Playing with the Bluetooth settings will solve your problem
When I try to renew the UPnP event subscription on the device, I have an 412 HTTP Error: Precondition Failed, bad SID.
This error occurs only on one device, all other devices works fine.
Buggy device is an D-Link XTreme N GIGABIT Router DIR-655 (Firmware Version :1.34WW, 2010/09/30), H/w ver: A4.
UPNP subscription log (catched by Wireshark)
Subscription:
SUBSCRIBE /l3fw HTTP/1.0
Host: 192.168.0.1
CALLBACK: <http://192.168.0.100:7169/evt/43E47718-E7F6-D950-A503-71346C1D9944>
NT: upnp:event
TIMEOUT: Second-60
HTTP/1.1 200 OK
SID: uuid:5B68F900-2863-104D-8000-002401F35BC2
TIMEOUT: Second-60
SERVER: ipOS/7.6 UPnP/1.0 ipGENADevice/1.0
Renewal:
SUBSCRIBE /l3fw HTTP/1.0
Host: 192.168.0.1
SID: uuid:5B68F900-2863-104D-8000-002401F35BC2
TIMEOUT: Second-60
HTTP/1.1 412 Precondition Failed, bad SID
SERVER: ipOS/7.6 UPnP/1.0 ipGENADevice/1.0
First time I try to renew subscription in 5 seconds before expiration, e.g. on 55th second after initial subscription. Second try: on 45th second, but with the same effect.
Also I tried to use HTTP/1.1 in subscription requests (and add "Connection:close" header), but there is no effect.
What I'm doing wrong?
UPD1 Updating formware to 1.37WW changes nothing
UPD2
When I try to renew subscription immediately after subscribe, it works. Wait 750ms and renew - works. Wait 900ms and renew - fails with HTTP 412. It seems that there is a bugs in D-Link equipment (another D-Link router DI-624 works in the same manner). Intel device validator (https://software.intel.com/en-us/articles/intel-tools-for-upnp-technologies) validates DIR-655 and DI-624 eventing without errors, but, I think, there is no pause between subscribing and renewal steps. So, I think, UPNP eventing is not a reliable mechanism and it is better don't to use it.
Such device behavior compromises an upnp eventing mechanism idea.
I've just hit a very similar problem with some Belkin WeMo devices.
I solved my problem by making sure I responded properly to notification messages sent to the CALLBACK URL. I sent a HTTP 200 response and things started to work properly for me.
I've implemented connection recovery and want to reliably re-create a heartbeat timeout (ping/pong response timeout) during my test cycles. It appears that heartbeat is local between sender and receiver device? --- i am able to create sufficient network load to cause all of my other apps to time out.
I frequently get an intermittent "DisconnectWithError" event, but of course not frequent enough when I'm in my test cycle.
Perhaps I could take a walk outside the wifi range or programmatically disconnect and then invoke my error path (is there such a way? deviceManager.disconnect is not the way), but I was hoping for a more "engineering friendly external control" to cause the timeout. Any thoughts or experiences?
log during hb timeout:
13:17:01 myapp[2588] : -[GCKHeartbeatChannel heartbeatTimerDidFire] Ping out
13:17:01 myapp[2588] : -[GCKHeartbeatChannel inactivityTimerDidFire] Max ping messages sent with no reponse - firing failure message!
13:17:01 myapp[2588] : -[GCKDeviceManager heartbeatChannelDidTimeout:] Receiver not responding to heartbeat, disconnecting.
13:17:01 myapp[2588] : -[GCKCastSocket disconnect] disconnect
13:17:01 myapp[2588] : -[GCKCastSocket disconnect] waiting for write buffer to drain
13:17:01 myapp[2588] : -[GCKCastSocket doTeardownWithError:] doTeardownWithError
13:17:01 myapp[2588] : -[GCKCastSocket doTeardownWithError:] notifying delegate that socket is disconnected
13:17:01 myapp[2588] : -[GCKHeartbeatChannel didDisconnect] disconnected - stopping heartbeat timer if necessary
another way i've been been able to programmatically cause a disconnect is by having another device or emulator attempt to get the Chromecast connection, which causes the app under test to get the disconnect event.
I can't find much documentation to say whether this is supposed to happen or not:
Some thread opens a TCP (or other stream) socket
Thread 1 starts a blocking recv()
Thread 2 calls shutdown() on the socket with SHUT_RDWR (or SHUT_RD I think)
Thread 1 is now "woken up" from its blocking call, and returns zero, as it would if the other party closed its socket.
This behaviour appears on modern Linux and FreeBSD systems. I haven't tested it with any others.
A comment on a Microsoft MSDN help page here: http://msdn.microsoft.com/en-us/library/windows/desktop/ms740481%28v=vs.85%29.aspx suggests that this behaviour is "responsible" in Windows; it also states that this is "not currently the case" but this may be out of date.
Is this behaviour specified anywhere? Can I rely on it?
I don't think you can rely on it. shutdown() initiales socket shutdown, but the details depend on particular circumstances. Some protocols may indeed close connection and socket immediately which would wake up processes sleeping on that socket. In other cases, shutdown just kicks protocol state machine into action, but it would take some time until it would get to the point where it would make sense to wake up anyone. For instance, established TCP connection would have to transition through few states until it reaches CLOSED state. You will eventually wake up, but you can't rely on it happening right away.