We have the following setup for webrtc two-way video and audio streaming:
Mobile
Android application using Google WebRTC implementation java wrapper. Tested these two libs:
implementation 'org.webrtc:google-webrtc:1.0.+'
implementation 'com.github.webrtc-sdk:android:92.4515.03' // https://github.com/webrtc-sdk/android
RPi
Gstreamer with WebRTC plugin based on gst-examples with a few modifications.
Browser
Also slightly modified gst-examples Javascript implementation. It is based on native browser WebRTC support.
TURN
Coturn server working in Docker (coturn/coturn).
The problem
When calling from RPi to browser or mobile to browser everything works fine both in local network and via Internet (through TURN server). However when trying to connect RPi and Android device via Internet it gets stuck (local network works as well). The devices communicate with each other, negotiate SDPs and ICE candidates and the TURN server opens the connections properly, but there is no audio/video.
When looking at Android logs, the first difference is that there is no ICE connection change triggered:
PeerConnectionObserver: onStandardizedIceConnectionChange: CHECKING
nor
PeerConnectionObserver: onConnectionChange: CONNECTING
which happens before ICE candidates exchange. After ICE candidates have been sent there is no further communication with the other device and no status changes are being fired. Like for example these in the working case:
PeerConnectionObserver: onSelectedCandidatePairChanged: org.webrtc.CandidatePairChangeEvent#a856333
PeerConnectionObserver: onStandardizedIceConnectionChange: CONNECTED
PeerConnectionObserver: onConnectionChange: CONNECTED
PeerConnectionObserver: onIceConnectionChange CONNECTED
[Internal data channel]: onStateChange
PeerConnectionObserver: onDataChannel org.webrtc.DataChannel#b76f6f0
[External data channel]: onStateChange
The coturn logs don't show anything suspicious at all.
Would appreciate any tips or help of any kind in further investigating this issue.
EDIT:
With #RSATom suggestion we've looked more closely to ICE and SDP messages being sent and found no discrapancies there. The SDPs are identical for mobile-RPi communication through Internet and locally. The only difference are ids generated randomly. The ICEs also do not differ much. It's identical for the first sender (offerer) and slightly different for answerer because it contains the TURN details:
via Internet
video0:0:candidate:228040959 1 udp 2122260223 10.111.215.156 53556 typ host generation 0 ufrag 3SNh network-id 3 network-cost 900::UNKNOWN
video0:0:candidate:559267639 1 udp 2122202367 ::1 48566 typ host generation 0 ufrag 3SNh network-id 2::UNKNOWN
video0:0:candidate:1510613869 1 udp 2122129151 127.0.0.1 41279 typ host generation 0 ufrag 3SNh network-id 1::UNKNOWN
video0:0:candidate:1876313031 1 tcp 1518222591 ::1 46051 typ host tcptype passive generation 0 ufrag 3SNh network-id 2::UNKNOWN
video0:0:candidate:344579997 1 tcp 1518149375 127.0.0.1 60259 typ host tcptype passive generation 0 ufrag 3SNh network-id 1::UNKNOWN
video0:0:candidate:842163049 1 udp 1686052607 31.0.91.196 6742 typ srflx raddr 10.111.215.156 rport 53556 generation 0 ufrag 3SNh network-id 3 network-cost 900:stun:3.70.23.20:3478:UNKNOWN
video0:0:candidate:593469510 1 udp 41885439 172.31.0.169 14307 typ relay raddr 31.0.91.196 rport 6742 generation 0 ufrag 3SNh network-id 3 network-cost 900:turn:3.70.23.20:3478?transport=udp:UNKNOWN
via local WiFi
video0:0:candidate:2858526953 1 udp 2122260223 192.168.0.21 38123 typ host generation 0 ufrag rwx/ network-id 3 network-cost 10::UNKNOWN
video0:0:candidate:559267639 1 udp 2122202367 ::1 52058 typ host generation 0 ufrag rwx/ network-id 2::UNKNOWN
video0:0:candidate:1510613869 1 udp 2122129151 127.0.0.1 39469 typ host generation 0 ufrag rwx/ network-id 1::UNKNOWN
video0:0:candidate:842163049 1 udp 1686052607 178.235.191.135 13607 typ srflx raddr 192.168.0.21 rport 38123 generation 0 ufrag rwx/ network-id 3 network-cost 10:stun:3.70.23.20:3478:UNKNOWN
video0:0:candidate:1876313031 1 tcp 1518222591 ::1 51551 typ host tcptype passive generation 0 ufrag rwx/ network-id 2::UNKNOWN
video0:0:candidate:344579997 1 tcp 1518149375 127.0.0.1 41007 typ host tcptype passive generation 0 ufrag rwx/ network-id 1::UNKNOWN
video0:0:candidate:593469510 1 udp 41885439 172.31.0.169 13744 typ relay raddr 178.235.191.135 rport 13607 generation 0 ufrag rwx/ network-id 3 network-cost 10:turn:3.70.23.20:3478?transport=udp:UNKNOWN
The order of ICE messages seems not to be persisted.
A diff of full logs (Internet left, local right): https://www.diffchecker.com/elEA6rkJ
ICE messages diff: https://www.diffchecker.com/C1TzPcMm
EDIT 2:
I missed that some of the logs were not present. Full log diff for connectivity via Internet (working vs not-working) available here. There are a few differences:
Invalid connection misses a lot of logs informing of connection creation and keepalive and still displays this instead:
tag: basic_ice_controller.cc
message: (line 541): Sorting 0 available connections
For the invalid connection RTP SSRC transport_cc is turned off
Gstreamer uses stream aliases (like video0 and audio0) which then cause ICE candidate errors like this:
ReadyToUseRemoteCandidate: Invalid candidate. Mid 0 specified but no media section with that mid found.
There are failed TCP requests to TURN:
LS_INFO
tag: turn_port.cc
message: (line 375): Port[31f33800:video0:1:0:relay:Net[lo:127.0.0.x/8:Loopback:id=1]]: Trying to connect to TURN server via tcp # sicdev-turn.ddns.net:3478
LS_INFO
tag: android_network_monitor.cc
message: (line 422): Find network handle.
LS_WARNING
tag: android_network_monitor.cc
message: (line 307): BindSocketToNetwork unable to find network handle for addr: 127.0.0.x ifname: lo
LS_VERBOSE
tag: physical_socket_server.cc
message: (line 207): Binding socket to loopback address failed; result: -3
LS_ERROR
tag: basic_packet_socket_factory.cc
message: (line 186): TCP connect failed with error 22
LS_ERROR
tag: turn_port.cc
message: (line 379): Failed to create TURN client socket
What I would do in your case:
Add logs for create-offer/create-answer/set-offer/set-answer requests
Add logs for every incoming/outgoing Ice Candidate and end-of-candidates
Then look to logs and check:
All Ice Candidates are really delivering to other party.
end-of-candidates delivering after all other Ice Candidates.
Ice Candidates coming after set-offer/set-answer
Your STUN/TURN server is really accessible by both parties (with https://webrtc.github.io/samples/src/content/peerconnection/trickle-ice/)
You have IPv6 configured on your STUN/TURN server (some GSM providers could not use IPv4 at all)
Upd 1
According to logs your Android device has IPv4. So there is no need to worry about IPv6 right now.
About end-of-candidates - you can look how I generate it with webrtcbin here.
The similar code for Android:
private val connectionObserver = object: PeerConnection.Observer {
// ... some overrides skipped ...
override fun onIceCandidate(candidate: IceCandidate) {
Log.d(TAG, "onIceCandidate \"$candidate\"")
}
override fun onIceGatheringChange(state: PeerConnection.IceGatheringState) {
Log.d(TAG, "IceGathering state: $state")
if(state == PeerConnection.IceGatheringState.COMPLETE) {
Log.d(TAG, "onIceCandidate \"a=end-of-candidates\"")
}
}
// ... some overrides skipped ...
}
Also please check following:
On Android
You are really call org.webrtc.PeerConnection.addIceCandidate for every incoming Ice Candidate
You do it after org.webrtc.PeerConnection.setRemoteDescription call
On RPi
You are really call g_signal_emit_by_name with add-ice-candidate for every incoming Ice Candidate
Upd 2
I've noticed your relay Ice Candidate points to private network IP (172.31.0.169). This can mean you have wrong config for your TURN
server.
Upd 3
Please check with https://webrtc.github.io/samples/src/content/peerconnection/trickle-ice/ you get relay Ice Candidate with valid IP on both sides.
Related
My goal is to send a UDP message (smaller than 100 bytes) from a SmartWatch (running wear os 2) to an Arduino on the same network. As long as the SmartWatch stays connected to the wifi (ip address of the watch: 145.167.189.23) this works great.
But when I turn on bluetooth, the SmartWatch disables wifi and switches to an internet connection via the bluetooth connected phone.
The SmartWatch gets an ip address in a subnet of the internet connection from the mobile (if the mobile has the ip address 145.167.189.105, it gets 145.167.177.4). TCP requests, like 'stackoverflow.com' work fine.
If I now try to send a UDP message nothing arrives at the Arduino.
I already tried to send a UDP message to 255.255.255.255, 145.255.255.255, 145.167.255.255, 145.167.189.255, but nothing ever arrived at the Arduino ( verified by Wireshark).
Over six years ago there was the same problem (Simple UDP Broadcast not working on Android Wear), at that time wear os 2 was not available. The only proposed solution was the 'Wear Data Layer'. I already tried this as well, but observed very large latencies (about 3 seconds). Therefore, these do not represent a solution for me at all.
The documentation for network access on wear os only says
You can use protocols such as HTTP, TCP, and UDP
Maybe someone could give me a hint why the UDP messages are not forwarded from the phone.
Only DNS udp packages can be forwarded to the phone.
It setup some iptable rules to forward udp packages to the TPROXY. Look at the following rules (iptables -t mangle -L). It does't forward udp packges to Reserved IP addresses.
Chain oem_CW_PROXY_UDP (22 references)
target prot opt source destination
RETURN all -- anywhere 0.0.0.0/8
RETURN all -- anywhere loaclhost/8
RETURN all -- anywhere 100.64.0.0/10
RETURN all -- anywhere 127.0.0.0/8
RETURN all -- anywhere 169.254.0.0/16
RETURN all -- anywhere 172.16.0.0/12
RETURN all -- anywhere 192.0.0.0/29
RETURN all -- anywhere 192.0.2.0/24
RETURN all -- anywhere 192.168.0.0/16
RETURN all -- anywhere 198.18.0.0/15
RETURN all -- anywhere 198.51.100.0/24
RETURN all -- anywhere 203.0.113.0/24
RETURN all -- anywhere 224.0.0.0/4
RETURN all -- anywhere 240.0.0.0/4
RETURN all -- anywhere 255.255.255.255
TPROXY udp -- anywhere anywhere TPROXY redirect 0.0.0.0:35070 mark 0x1/0x1
The TPROXY will forward the reveived udp packcages to the phone throught bluetooth socket. But it will only forwoard DNS packages, which can be seen from the watch's logcat.
It seems that Wear OS decided to only forwoard DNS packages at some time.
05-20 12:20:31.269806 1263 5866 D HOME : [ClockworkProxyUdp]Got packet with 47 bytes, from: /192.168.167.239:36215 original dst: /8.8.8.8:53
05-20 12:21:05.264492 1263 5866 D HOME : [ClockworkProxyUdp]Got packet with 47 bytes, from: /192.168.167.239:63348 original dst: /8.8.8.8:53
05-20 12:21:05.272685 1263 5866 D HOME : [ClockworkProxyUdp]Got packet with 32 bytes, from: /192.168.167.239:34219 original dst: /8.8.8.8:53
05-20 12:21:38.282089 1263 5866 D HOME : [ClockworkProxyUdp]Got packet with 47 bytes, from: /192.168.167.239:54529 original dst: /8.8.8.8:53
05-20 12:21:38.287255 1263 5866 D HOME : [ClockworkProxyUdp]Got packet with 32 bytes, from: /192.168.167.239:58688 original dst: /8.8.8.8:53
I'm developing a WebRTC calling app, and I'm facing some weird issues with it. I chose PeerJS to make all the development easier, and it works good.
But I have a weird problem when it comes to network switching on Android and Crosswalk (Wifi to 3G).
The thing is that I can make a call from one end to the other one over Wifi and it works as expected. Then I switch to 3G on one end, make another call and it doesn't work.
The issue is that, when it is working over 3G, one end does not receives relay candidates. So it answers to host candidate but not to relay candidates which are the ones that I want to.
{"type":"OFFER","payload":{"sdp":{"type":"offer","sdp":"v=0\r\no=- 9207325897229143904 2 IN IP4 127.0.0.1\r\ns=-\r\nt=0 0\r\na=group:BUNDLE audio\r\na=msid-semantic: WMS sEJdVRbesv0A43zVIHpsjpBP97JHsJsnvIXh\r\nm=audio 9 UDP/TLS/RTP/SAVPF 111 103 9 0 8 106 105 13 126\r\nc=IN IP4 0.0.0.0\r\na=rtcp:9 IN IP4 0.0.0.0\r\na=ice-ufrag:XayiDeo/VebqhfvU\r\na=ice-pwd:nlhMhUoDBuMhQjeN7gVzmDZA\r\na=fingerprint:sha-256 A4:12:DA:AD:0F:60:63:F1:A8:50:C2:57:98:89:ED:77:43:B4:CF:2E:AA:F5:53:A7:90:97:12:B6:58:82:27:1F\r\na=setup:actpass\r\na=mid:audio\r\na=extmap:1 urn:ietf:params:rtp-hdrext:ssrc-audio-level\r\na=extmap:3 http://www.webrtc.org/experiments/rtp-hdrext/abs-send-time\r\na=sendrecv\r\na=rtcp-mux\r\na=rtpmap:111 opus/48000/2\r\na=fmtp:111 minptime=10; useinbandfec=1\r\na=rtpmap:103 ISAC/16000\r\na=rtpmap:9 G722/8000\r\na=rtpmap:0 PCMU/8000\r\na=rtpmap:8 PCMA/8000\r\na=rtpmap:106 CN/32000\r\na=rtpmap:105 CN/16000\r\na=rtpmap:13 CN/8000\r\na=rtpmap:126 telephone-event/8000\r\na=maxptime:60\r\na=ssrc:157434490 cname:qDTW7PBlwzV52rEW\r\na=ssrc:157434490 msid:sEJdVRbesv0A43zVIHpsjpBP97JHsJsnvIXh fa7fe6f0-5372-4573-a76d-09ff3bd18948\r\na=ssrc:157434490 mslabel:sEJdVRbesv0A43zVIHpsjpBP97JHsJsnvIXh\r\na=ssrc:157434490 label:fa7fe6f0-5372-4573-a76d-09ff3bd18948\r\n"},"type":"media","connectionId":"mc_00787gz767gmn29","browser":"Chrome"},"dst":"ZUQn45fuzC"}
{"type":"CANDIDATE","payload":{"candidate":{"candidate":"candidate:3747612131 1 tcp 1518280447 192.168.1.42 0 typ host tcptype active generation 0","sdpMid":"audio","sdpMLineIndex":0},"type":"media","connectionId":"mc_00787gz767gmn29"},"dst":"ZUQn45fuzC"}
{"type":"CANDIDATE","payload":{"candidate":{"candidate":"candidate:3747612131 2 tcp 1518280446 192.168.1.42 0 typ host tcptype active generation 0","sdpMid":"audio","sdpMLineIndex":0},"type":"media","connectionId":"mc_00787gz767gmn29"},"dst":"ZUQn45fuzC"}
{"type":"ANSWER","src":"ZUQn45fuzC","dst":"ZUQn45fuzC-908sf","payload":{"sdp":{"type":"answer","sdp":"v=0\r\no=- 4572206596343832202 2 IN IP4 127.0.0.1\r\ns=-\r\nt=0 0\r\na=group:BUNDLE audio\r\na=msid-semantic: WMS vd1JxmlIr4LBan1PD5paXYyHfyUhw1vEJY3k\r\nm=audio 9 UDP/TLS/RTP/SAVPF 111 103 9 0 8 106 105 13 126\r\nc=IN IP4 0.0.0.0\r\na=rtcp:9 IN IP4 0.0.0.0\r\na=ice-ufrag:mu+gTMWn5JTLdZvc\r\na=ice-pwd:jKodikIYat7TmAFstDOMkYLy\r\na=fingerprint:sha-256 7B:95:5E:62:D3:09:E3:39:45:F2:03:54:40:07:17:1A:55:61:6D:AC:F0:B1:0E:95:2E:89:A0:D4:F6:8D:D7:BC\r\na=setup:active\r\na=mid:audio\r\na=extmap:1 urn:ietf:params:rtp-hdrext:ssrc-audio-level\r\na=extmap:3 http://www.webrtc.org/experiments/rtp-hdrext/abs-send-time\r\na=sendrecv\r\na=rtcp-mux\r\na=rtpmap:111 opus/48000/2\r\na=fmtp:111 minptime=10; useinbandfec=1\r\na=rtpmap:103 ISAC/16000\r\na=rtpmap:9 G722/8000\r\na=rtpmap:0 PCMU/8000\r\na=rtpmap:8 PCMA/8000\r\na=rtpmap:106 CN/32000\r\na=rtpmap:105 CN/16000\r\na=rtpmap:13 CN/8000\r\na=rtpmap:126 telephone-event/8000\r\na=maxptime:60\r\na=ssrc:4261079885 cname:A48eZP6Rm+hQeX2p\r\na=ssrc:4261079885 msid:vd1JxmlIr4LBan1PD5paXYyHfyUhw1vEJY3k 60fbeb3f-0baf-4871-8be3-a5a2b002f4b0\r\na=ssrc:4261079885 mslabel:vd1JxmlIr4LBan1PD5paXYyHfyUhw1vEJY3k\r\na=ssrc:4261079885 label:60fbeb3f-0baf-4871-8be3-a5a2b002f4b0\r\n"},"type":"media","connectionId":"mc_00787gz767gmn29","browser":"Chrome"}}
{"type":"CANDIDATE","src":"ZUQn45fuzC","dst":"ZUQn45fuzC-908sf","payload":{"candidate":{"candidate":"candidate:1189248530 1 udp 2122260223 192.168.1.49 40726 typ host generation 0","sdpMid":"audio","sdpMLineIndex":0},"type":"media","connectionId":"mc_00787gz767gmn29"}}
{"type":"CANDIDATE","src":"ZUQn45fuzC","dst":"ZUQn45fuzC-908sf","payload":{"candidate":{"candidate":"candidate:2968651718 1 udp 1686052607 83.40.XXX.XXX 40726 typ srflx raddr 192.168.1.49 rport 40726 generation 0","sdpMid":"audio","sdpMLineIndex":0},"type":"media","connectionId":"mc_00787gz767gmn29"}}
{"type":"CANDIDATE","src":"ZUQn45fuzC","dst":"ZUQn45fuzC-908sf","payload":{"candidate":{"candidate":"candidate:140608226 1 tcp 1518280447 192.168.1.49 0 typ host tcptype active generation 0","sdpMid":"audio","sdpMLineIndex":0},"type":"media","connectionId":"mc_00787gz767gmn29"}}
{"type":"CANDIDATE","src":"ZUQn45fuzC","dst":"ZUQn45fuzC-908sf","payload":{"candidate":{"candidate":"candidate:729144661 1 udp 41885439 188.XXX.XXX.XXX 49360 typ relay raddr 83.40.XXX.XXX rport 40726 generation 0","sdpMid":"audio","sdpMLineIndex":0},"type":"media","connectionId":"mc_00787gz767gmn29"}}
I tested the connectivity between the TURN server and the device with this function, and it told me that the turn server was not available. When I switch back to Wifi everything works properly.
Is there any issue with android crosswalk with WebRTC? What could be happening here?. I have crosswalk version 18.
Thank you!
I want to discover all Android devices IP and Port in same wifi network using ZeroMQ?
My app basically connect all device in same wifi network (no internet needed) and message to each other. Once ip and port I know I am send message successfully but how to know all device internet Protocol (ip) Using ZeroMQ?
Principle
Part A)
Every IEEE 802.x CSMA/CD network "collision domain" ( wifi AP/SSID is such one ) has to be managed so as to work well. Thus the Address Resolution Protocol [ARP] will help you in the task to find all ISO-OSI-Layer-3 IP Addresses. Wifi Access Point [AP] host, to which all live devices register and handshake with, is the choice to start with.
HG520i> ip arp status
received 54205 badtype 0 bogus addr 0 reqst in 12105 replies 196 reqst out 14301
cache hit 63152696 (24%), cache miss 19455672 (23%)
IP-addr Type Time Addr stat iface
192.168.0.230 10 Mb Ethernet 290 00:15:af:e6:b1:79 41 enif0
192.168.0.62 10 Mb Ethernet 300 00:0c:29:98:d4:3b 41 enif0
192.168.0.55 10 Mb Ethernet 300 00:27:0e:07:c5:9e 41 enif0
192.168.0.255 10 Mb Ethernet 0 ff:ff:ff:ff:ff:ff 43 NULL
num of arp entries= 4
Part B)
Scanning all the ports on all the known IP hosts is a dumb brute force approach to the second issue.
Scanning just a subset of "reasonable" ones would save you both the time and efforts on peer-recognitions.
Using some smarter, active "visibility self-advertisement policy" will save you even more.
Solution
Decide on multi-party system architecture, whether an individual passive scan, a central/distributed proxy-assisted scan or an active self-advertisement policy will be used to build and maintain live records in a neighbouring hosts register.
ZeroMQ per-se brings you a lot of power for the smart solutions, while the dumb-force solutions would have to wait till fully fledged ZeroMQ services will be ready. Low level L2/L3-inspections will have to bring their fruit before ZeroMQ can first .bind()/.connect()
Needless to say, that uncoordinated CSMA/CD networks do not guarantee that all the L2-visible hosts will have "compatible" L3-ip-adddress ( will belong to / have the same L3-ip-network address ).
Thus you never know about all IP addresses without a truly low-level sniffer.
I have downloaded nfcpy and successfully ran the beam examples.
I use the beam.py to send data from a RPi with PN532 NFC chip to a Nexus Android phone, the data is sent correctly but on the RPi the python script does not exist as long as I keep the phone next to the reader.
The question applies to sending and receiving from nfcpy.
What do I have to do for the beam.py to exist
safely ?
Example:
Sending:
./beam.py --device tty:AMA0:pn53x send ndef start.ndef
[nfc.clf] searching for reader with path 'tty:AMA0:pn53x'
[nfc.clf] using NXP PN532 at /dev/ttyAMA0
[nfc.snep.server] snep server bound to port 4 (MIU=1984, RW=15), will accept up to 1048576 byte NDEF messages
[nfc.dev.pn53x] activated as target in 424 kbps active mode
[nfc.dev.pn53x] [Errno 110] Connection timed out
[nfc.dev.pn53x] activated a p2p target in 424 kbps active mode
[nfc.llcp.llc] LLCP Link established as NFC-DEP Initiator
Local LLCP Settings
LLCP Version: 1.1
Link Timeout: 500 ms
Max Inf Unit: 2175 octet
Service List: 0000000000010011
Remote LLCP Settings
LLCP Version: 1.1
Link Timeout: 1500 ms
Max Inf Unit: 128 octet
Service List: 0000000000010011
[nfc.dev.pn53x] [PN53x Error 0x13] Format error during RF communication
Receiving:
./beam.py --device tty:AMA0:pn53x recv print
[nfc.clf] searching for reader with path 'tty:AMA0:pn53x'
[nfc.clf] using NXP PN532 at /dev/ttyAMA0
[nfc.snep.server] snep server bound to port 4 (MIU=1984, RW=15), will accept up to 1048576 byte NDEF messages
[nfc.dev.pn53x] activated as target in 424 kbps active mode
[nfc.dev.pn53x] [Errno 110] Connection timed out
[nfc.dev.pn53x] activated a p2p target in 424 kbps active mode
[nfc.llcp.llc] LLCP Link established as NFC-DEP Initiator
Local LLCP Settings
LLCP Version: 1.1
Link Timeout: 500 ms
Max Inf Unit: 2175 octet
Service List: 0000000000010011
Remote LLCP Settings
LLCP Version: 1.1
Link Timeout: 1500 ms
Max Inf Unit: 128 octet
Service List: 0000000000010011
[nfc.llcp.tco] accepting CONNECT from SAP 32
[nfc.snep.server] serving snep client on remote sap 32
[main] default snep server got put request
[main] print ndef message 'application/com.example.android.beam'
record 1
type = 'application/com.example.android.beam'
name = ''
data = 'Beam me up!\n\nBeam Time: 15:11:22\n'
record 2
type = 'urn:nfc:ext:android.com:pkg'
name = ''
data = 'com.example.android.beam'
[nfc.dev.pn53x] [PN53x Error 0x13] Format error during RF communication
The most natural way that an NFC P2P link terminates is with some error caused by link disruption. For as long as both devices are in proximity, the communication will just continue with exchange of symmetry packets. This way either device may start other conversations as it wishes - SNEP (or beam) is not just the only thing.
Specifically for nfcpy's beam example, the way to terminate earlier is by Ctrl-C. Or to modify the example to terminate when the task is done.
I'm having issues with using some sockets in C++ code with Android NDK. Two sockets are created, and one reads from the other. This works with a network connection on Android, both with and without a network connection on another machine, but NOT on Android without a network connection.
Here is a netstat output before the socket closes. The line of interest is
tcp 0 0 127.0.0.1:32993 127.0.0.1:46810 ESTABLISHED
Proto Recv-Q Send-Q Local Address Foreign Address State
tcp 0 0 0.0.0.0:32993 0.0.0.0:* LISTEN
tcp 0 0 0.0.0.0:45549 0.0.0.0:* LISTEN
tcp 0 0 127.0.0.1:5037 0.0.0.0:* LISTEN
tcp 0 0 0.0.0.0:5555 0.0.0.0:* LISTEN
tcp 0 0 127.0.0.1:46811 127.0.0.1:32993 ESTABLISHED
tcp 0 0 127.0.0.1:32993 127.0.0.1:46811 ESTABLISHED
tcp 0 0 127.0.0.1:46810 127.0.0.1:32993 ESTABLISHED
tcp 0 0 127.0.0.1:32993 127.0.0.1:46810 ESTABLISHED
tcp 0 0 10.0.2.15:5555 10.0.2.2:34217 ESTABLISHED
udp 0 0 10.0.2.15:49667 10.0.2.3:53
udp 0 0 0.0.0.0:60262 0.0.0.0:*
I then attempt to read 10 bytes from the socket 127.0.0.1:46810 (header_length - filled = 10):
bytes = read(fd, header, header_length - filled);
However, 0 bytes are read. TCP_NODELAY has been set on the socket. This is the netstat output after the read.
Proto Recv-Q Send-Q Local Address Foreign Address State
tcp 0 0 0.0.0.0:32993 0.0.0.0:* LISTEN
tcp 0 0 127.0.0.1:5037 0.0.0.0:* LISTEN
tcp 0 0 0.0.0.0:5555 0.0.0.0:* LISTEN
tcp 0 0 127.0.0.1:46811 127.0.0.1:32993 FIN_WAIT2
tcp 0 1 127.0.0.1:32993 127.0.0.1:46811 CLOSE_WAIT
tcp 0 0 127.0.0.1:46810 127.0.0.1:32993 FIN_WAIT2
tcp 0 0 127.0.0.1:32993 127.0.0.1:46810 CLOSE_WAIT
tcp 0 0 10.0.2.15:5555 10.0.2.2:34217 ESTABLISHED
udp 0 0 0.0.0.0:60262 0.0.0.0:*
There are no problems when there is a network connection, and the addresses used are still 127.0.0.1. Why would it fail to read any bytes on localhost when there is no network connection?
Turns out that this was being caused by another issue. Some time after resolving the IP address into a char array, delete[] was being called on the array. When there was no network connection, the pointer was being reassigned directly to 127.0.0.1, so the program was crashing on the delete[]. Copying the IP into the array using
strcpy(ip, "127.0.0.1");
means that the pointer still points at the array, and the program does not crash when calling delete[].