ICE protocol what is base? - webrtc

In ICE protocol, What is Base?
I understood Base as, for the server reflexive candidate , host candidate is the base, is it correct or not?
How to find the foundation of the candidate?

You are correct. According RFC5245 :
Base: The base of a server reflexive candidate is the host candidate
from which it was derived. A host candidate is also said to have a
base, equal to that candidate itself. Similarly, the base of a
relayed candidate is that candidate itself.
The foundation is an arbitrary value. You can find it for each ICE candidates in the SDP. It is the first value after candidate:
For example
a=candidate:1174096638 1 udp 2122194687 10.191.1.117 57105 typ host generation 0
a=candidate:2999745851 1 udp 2122129151 192.168.59.1 57106 typ host generation 0
Foundations are
1174096638
2999745851

Related

Determine NAT Mapping Behaviour using two STUN servers

is it possible to determine the mapping behaviour of a NAT using two STUN servers? something like here.
There are three types of mapping behaviour:
Endpoint-Independent Mapping:The NAT reuses the port mapping for subsequent packets sent from the same internal IP address and port (X:x) to any external IP address and port. Specifically, X1′:x1′ equals X2′:x2′ for all Y.
Address-Dependent Mapping: The NAT reuses the port mapping for subsequent packets sent from the same internal IP address and port (X:x) to the same external IP address, regardless of the external port. Specifically, X1′:x1′ equals X2′:x2′ if and only if, Y2 equals Y1.
Address and Port-Dependent Mapping:The NAT reuses the port mapping for subsequent packets sent from the same internal IP address and port (X:x) to the same external IP address and port while the mapping is still active. Specifically, X1′:x1′ equals X2′:x2′ if and only if, Y2:y2 equals Y1:y1.
So in theory if you ask two different STUN servers for your public IP address and you get the same IP:port, you should have an Endpoint-Independent Mapping right? but how do you differentiate the other two types?
I would try setting up two stun servers on different ports on the same host.
So you will need 3 stun servers in total: two on the same host and one on other.
If you get 3 different candidates, it must be address and port dependent mapping; 2 means address-dependent; 1 - endpoint-dependent; 0 - udp is probably blocked.
But this approach needs to be tested thoroughly, I believe there might be some browser-dependent surprises (see esser50k comment in the article you provided).

DPDK SRIOV multiple vlan traffic over single VF of SRIOV passthrough

When trying to use RTE API's for VLAN offload and VLAN filtering I observe that both VLAN tagged and untagged packets are being sent out.
API's used:
rte_eth_dev_set_vlan_offload ,
rte_eth_dev_vlan_filter
DPDK - 18.08
RHEL - 7.6
Driver - igb_uio
Is there a way to allow only VLAN tagged packets to be sent out?
Regards,
Not sure if I understand correctly - you're trying to strip vlan tags from tx packets? Why would you want to offload that? If you forward packets from somewhere else they already have their tags stripped by rx offload. If you create them yourself, well - you're in control.
Regardless, if you'd want to offload tx vlan insertion:
rte_eth_dev_set_vlan_offload only sets RX offload flags.
You'll probably have to set the tx offload flag in your port config manually, like in this abridged snippet from the DPDK Flow Filtering example code:
struct rte_eth_conf port_conf = {
.txmode = {
.offloads =
DEV_TX_OFFLOAD_VLAN_INSERT,
},
};

How to use DCCP with twisted ? (Datagram Congestion Control Protocol)

At the interface level DCCP is like TCP: you connect and then send/receive bytes.
I was wondering it's possible to make dccp connections in twisted by just adapting the wrappers for tcp...
According to the sample code (below) what needs to be changed is:
at socket instantiation: use different parameters
before using the socket: set some options
Then everything else would be the same...
Hints: I've spotted addressFamily and socketType in the sources of twisted but I have no idea on how to cleanly set them in the protocol factory. Also the protocol number, the 3rd parameter, here IPPROTO_DCCP, is always keeped to default. I have no clue either on how to access the socket to call setsockopt
import socket
socket.DCCP_SOCKOPT_PACKET_SIZE = 1
socket.DCCP_SOCKOPT_SERVICE = 2
socket.SOCK_DCCP = 6
socket.IPPROTO_DCCP = 33
socket.SOL_DCCP = 269
packet_size = 256
address = (socket.gethostname(),12345)
# Create sockets
server,client = [socket.socket(socket.AF_INET, socket.SOCK_DCCP,
socket.IPPROTO_DCCP) for i in range(2)]
for s in (server,client):
s.setsockopt(socket.SOL_DCCP, socket.DCCP_SOCKOPT_PACKET_SIZE, packet_size)
s.setsockopt(socket.SOL_DCCP, socket.DCCP_SOCKOPT_SERVICE, True)
# Connect sockets
server.bind(address)
server.listen(1)
client.connect(address)
s,a = server.accept()
# Echo
while True:
client.send(raw_input("IN: "))
print "OUT:", s.recv(1024)
More about DCCP:
https://www.sjero.net/research/dccp/
https://wiki.linuxfoundation.org/networking/dccp
TL;DR: dccp is a protocol that provides congestion control (like tcp) without guaranteeing reliability or in-order delivery of data (like udp). The standard linux kernel implements dccp.

Signaling on RTCPeerconnection

I wrote a simple code for testing RTCPeerconnection
peer = new RTCPeerconnection(...);
peer.onicecandidate = function(evt){
console.log(evt.candidate);
// into the console
// RTCIceCandidate {candidate: "candidate:... 1 udp ", sdpMLineIndex:0, sdpMid:"data"}
// RTCIceCandidate {candidate: "candidate:... 2 udp ", sdpMLineIndex:0, sdpMid:"data"}
}
i want send it to signaling server but i receive it 2 times and 2 different values.
Have i to record all candidate values?
When i receive candidate information from signaling server, have i to receive all the values about the same peer?
I have too, localDescription
// {type: "offer", sdp: "v=0↵o=- 6483...48 2 IN IP4 ...}
Have i to send it to signaling server and receive the description of other peer?
I think you need to do bit more reading up on WebRTC, for a single PeerConnection, there could be many ICE candidates, you usually send it to remote peer through some signaling server, no point storing it in server, as they probably expire after a period of time.
this and this might be good place to read up on the basics.

Discarded UDP datagram over MTU size with IPv6

I've found out that when I send an UDP datagram that gets fragmented (over 1452 bytes with MTU=1500), according to tcpdump, all the fragments are received on the target machine but then no message is received on the socket. This happens only with IPv6 addresses (both global and link-local), with IPv4 everything works as expected (and with non-fragmented datagrams as well).
As the datagram is discarded, there is this ICMP6 message:
05:10:59.887920 IP6 (hlim 64, next-header ICMPv6 (58) payload length: 69) 2620:52:0:105f::ffff:74 > 2620:52:0:105f::ffff:7b: [icmp6 sum ok] ICMP6, destination unreachable, length 69, unreachable port[|icmp6]
There's some repeated neighbour solicitation/advertisements going on and I see that it gets to the ARP cache (via ip neigh).
One minute later I get another ICMP6 messages saying that the fragment has timeout out.
What's wrong with the settings? The reassembled packet should not be discarded, when it can be delivered, right?
System is RHEL6 2.6.32-358.11.1.el6.x86_64