Rebol 2 port binding to multiple IPs - rebol

I have a Windows setup with multiple IP's, and wishes my Rebol script (on Rebol/Core 2.78) to make individual bind and listen to the same port number on each of those IP's.
Until very recently I thought the syntax to do this was:
Port1Test: open/lines tcp://:80 browse http://10.100.44.6?
Port2Test: open/lines tcp://:80 browse http://10.100.44.7?
But it turns out the Port2Test line fails, as the browse http://10.100.44.6? part is totally ignored (and now searching, I can't even locate where I got that syntax in the first place).
Reading up on the documentation all I can find on how to specify a listening port is like this:
Port1Test: open/lines tcp://:80
Probing the Port1Test port reveals most settings set to none, and a few set as follows:
scheme: 'tcp
host: none
port-id: 80
local-ip: 0.0.0.0
local-port: 80
So I attempted to modify those values like this:
Port1Test: open/lines tcp://:80 ; Create port, as before. Then modify below
Port1Test/host: 10.100.44.6 ; Might this be the binding interface?
Port1Test/port-id: 1 ; I guess this is just an id?
Port1Test/local-ip: 10.100.44.6 ; This ought to be the binding interface.
Port2Test: open/lines tcp://:80 ; Create port, as before. Then modify below
Port2Test/host: 10.100.44.7 ; Might this be the binding interface?
Port2Test/port-id: 2 ; I guess this is just an id?
Port2Test/local-ip: 10.100.44.7 ; This ought to be the binding interface.
Unfortunately all variations of the above modifications, including swapping the IP values for Port1Test and Port2Test, fails when creating Port2Test. :-(
I'm sure there's something I'm overlooking, but I can't find any hints anywhere about how to initialize a port while binding it to a specific interface.
Any hints highly appreciated!
Edit:
The way Rebol bind to interfaces is now pretty evident to me - but how to modify it it still a mystery.
Let’s say I have two IP’s (== interfaces) associated to one networking card: 10.100.1.1 and 10.100.1.2.
On 10.100.1.1:80 I setup a Tomcat application that I know can bind to that specific interface.
Then I start a REBOL application, that also claim port 80.
They will both run happily, and each be accessible on only one IP, as if the Rebol application had bound to 10.100.1.2.
Then I shut down the Tomcat application, and attempt to start it. This turns out not to be possible, as the interface is in use.
And if I access both of the IP’s, it turns out the Rebol application is accessible on both IP’s.
It’s not an active mechanism in Rebol that at work here, but because Rebol claims the 0.0.0.0 interfaces (In the context of servers, 0.0.0.0 means "all IPv4 addresses on the local machine"), which is translated to any currently available interface, and a deferred claim to interfaces as they become available.
It would be really nice to find out how to change Rebols default interface of 0.0.0.0 to something else at create time of the port!

Rebol2 listen ports bind by default to all available IPv4 interfaces (0.0.0.0), and to the extent of my knowledge, unfortunately, there is no way to change that.
FYI, Rebol2 exposes existing IPv4 interfaces using the interfaces port mode:
>> p: open tcp://:8000
>> probe get-modes p 'interfaces
[make object! [
name: "if19"
addr: 10.27.10.110
netmask: 255.255.255.252
broadcast: 10.27.10.111
dest-addr: none
flags: [broadcast multicast]
] make object! [
name: "lo0"
addr: 127.0.0.1
netmask: 255.0.0.0
broadcast: none
dest-addr: none
flags: [multicast loopback]
] make object! [
name: "if16"
addr: 192.168.1.4
netmask: 255.255.255.0
broadcast: 192.168.1.255
dest-addr: none
flags: [broadcast multicast]
]]
Alas, this is read-only...(the documentation says not settable).
You can find a list of all port modes here, in case it is of any help to you.

Related

UDP Broadcast to all nodes

I am trying to solve OMNET++ Ad hoc wireless UDP message to all nodes. My config file is as:
<config>
<interface hosts='host*' address='192.168.0.x' netmask='255.255.255.x'/>
<interface hosts='*' address='192.x.x.x' netmask='255.255.255.x'/>
</config>
and in ini file
*.host*.app[0].destAddresses = "255.255.255.255"
but this is not working. destAddress can be set as
*.host*.app[0].destAddresses=moduleListByNedType("inet.node.inet.AdhocHost")
but this still randomly chooses one host at a time. How can I send packets to all nodes/hosts.
Indeed, 255.255.255.255 is a broadcast address, but if you are using Adhoc routing the various nodes are routers and the broadcast is not forwarded by them. If you insist using UDP you MUST modify the INET sources to support sending to multiple destinations instead of randomly choosing one. You can also use PingApp which does behave as you expect (i.e. if you specify * as a destination address it pings ALL node interfaces in the simulation).
If you need UDP, you should take a look at the PingApp sources and get an inspiration from there to modify the UDPBasicApp.

RTCIceCandidate no longer returning IP

Just noticed that on Chrome only, RTCIceCandidate no longer returns an IP, but rather an obfuscated address.
RTCIceCandidate
address: "a5b3ef18-2e66-4e24-91d2-893b93bbc1c1.local"
candidate: "candidate:169888242 1 udp 2113937151 a5b3ef18-2e66-4e24-91d2-893b93bbc1c1.local 47871 typ host generation 0 ufrag 7dHv network-cost 999"
component: "rtp"
foundation: "169888242"
port: 47871
priority: 2113937151
protocol: "udp"
relatedAddress: null
relatedPort: null
sdpMLineIndex: 0
sdpMid: "0"
tcpType: ""
type: "host"
usernameFragment: "7dHv"
Notice the first property of RTCIceCanadate is "address", and "ip" is no longer part of this object.
The following code determines the local IP address of a browser. Still works on MOZ.
function discover()
{
try{
//Get Local IP
window.RTCPeerConnection = window.RTCPeerConnection || window.mozRTCPeerConnection || window.webkitRTCPeerConnection; //compatibility for firefox and chrome
if (pc)
pc.close();
pc = new RTCPeerConnection({iceServers:[]});
pc.onicecandidate = onIceCandidate;
pc.createDataChannel("");
pc.createOffer(pc.setLocalDescription.bind(pc), noop);
} catch (e)
{ console.log(e.message);}
}
function noop()
{
}
function onIceCandidate(ice)
{
console.log(ice.candidate);
if(!ice || !ice.candidate || !ice.candidate.candidate) return;
var my_ip = /([0-9]{1,3}(\.[0-9]{1,3}){3}|[a-f0-9]{1,4}(:[a-f0-9]{1,4}){7})/.exec(ice.candidate.candidate)[1];
this.onicecandidate = noop;
ip = my_ip.split(".")[0]+'.'+my_ip.split(".")[1]+'.'+my_ip.split(".")[2];
}
Is WebRTC officially now a fractured standard? MOZ still lists "ip" as a member of RTCIceCandidate, with no mention of the "address" member that Chrome returns.
Is there a way to de-obfusucate the mDNS address back to an ip address without forcing users to mess around with browser settings they don't understand?
Chrome is not broken, the WebRTC standard is evolving to prevent sites from collecting local addresses by diverting the WebRTC API. If you used this hack to obtain local addresses, you might need to find another approach.
Here are the corresponding issues for Chromium and Firefox, and the current IETF draft for WebRTC mDNS candidates.
The ip field got renamed to address in the W3C webrtc specification at some point since these days the field can contain either an IP address or a mdns hostname.
What you are seeing is part of the rollout of the WebRTC host candidate obfuscation which is described ħere which is happening in Chrome 75. You can not decode this mdns hostname in the browser.
If you have a legitimate use-case you might want to ask for it to be considered in that mailing list thread.
You can disable this feature in Chrome
goto chrome:://flags
and disable "Anonymize local IPs exposed by WebRTC"
I noticed that this was happening, only returning an mDNS address (for more information about the obfuscation, read this great article completely explaining what happened).
However, I did find a new repository that seems to "fix" this (working, but not exposing the private ip, only the public). It can be found here, and the example can be found here.

Timeout during allocate while making RFC call

I am trying to create a SAP RFC connection to a new system.
AFAIK the firewall (in this case to port 3321) is open.
I get this message at the client:
RFC_COMMUNICATION_FAILURE (rc=1): key=RFC_COMMUNICATION_FAILURE, message=
LOCATION SAP-Gateway on host ax-swb-q06.prod.lokal / sapgw21
ERROR timeout during allocate
TIME Thu Jul 26 16:45:48 2018
RELEASE 753
COMPONENT SAP-Gateway
VERSION 2
RC 242
MODULE /bas/753_REL/src/krn/si/gw/gwr3cpic.c
LINE 2210
DETAIL no connect of TP sapdp21 from host 10.190.10.32 after 20 sec
COUNTER 3
[MSG: class=, type=, number=, v1-4:=;;;]
And this message on the SAP server
Any clue what needs to be done, to get RFC working?
With this little info no one can know what the issue is here.
But it is something related to your network and SAP system configuration.
I guess your firewall does some network address translation (NAT) and the new IP behind the firewall does not match anymore with the known one. SAP is doing some own IP / host name security checks.
If not already done, check with opening the ports 3221, 3321 and 4821 in the firewall. Also check the SAP gateway configuration which IP addresses and host names are configured to be valid ones for it (look at what is traced in the beginning of the gateway trace file dev_rd at ABAP side).
Also consider if maybe the usage of a SAProuter would be the better option for your needs.
it works in my case if ashost is the host name, and not an IP address!
Do not ask me why, but this fails:
Connection(user='x', passwd='...', ashost='10.190.10.32', sysnr='21', client='494')
But this works:
Connection(user='x', passwd='...', ashost='ax-swb-q06.prod.lokal', sysnr='21', client='494')
This is strange, since DNS resolution happens before TCP communication.
It seems that the ashost value gets used inside the connection. Strange. For most normal protocols (http, ftp, pop3, ...) this does not matter. Or you get at least a better error message.

resolve.conf (generated) wrong order? (2 routers)

I have 2 routers in my network.
A) The one issued by my ISP (limited settings, had even to ask to get portforwarding settings), which is alo my modem.
B) My own router (wher i set my DHCP etc)
Now the generated resolve.txt on raspberrian and archlinux list:
domain local
nameserver <IP of A>
nameserver <IP of B>
As in understand it this is the order it will try to use when resolving names, but her it schould try my internal B before trying to resolve using A.
PS: Both subnetmasks are 255.255.255.0
Router A has 192.168.0.1
Router B has 192.168.1.1
All devices are in the 192.168.1.### range.
PPS: Archlinux is setup to use networkmanager, not a manual configured dhcpcd
NetworkManager may use dnsmasq for dhcp and to handle dns lookups.
I noticed that dnsmasq reverses the order of nameservers. Look at your logs. That would show up better in log if we also set dnsmasq to call dns servers in parallel:
#/etc/dnsmasq.conf
#all-servers
#/etc/dnsmasq.d/laptop.conf
all-servers
log-queries=extra
log-async=100
log-dhcp
#/etc/dnsmasq.d/servers.conf
server=66.187.76.168
server=162.248.241.94
server=165.227.22.116
/var/log/dnsmasq.log--
Mar 14 02:14:20 dnsmasq[3216]: 71700 127.0.0.1/38951 cached firefox.settings.services.mozilla.com is <CNAME>
Mar 14 02:14:20 dnsmasq[3216]: 71700 127.0.0.1/38951 forwarded firefox.settings.services.mozilla.com to 165.227.22.116
Mar 14 02:14:20 dnsmasq[3216]: 71700 127.0.0.1/38951 forwarded firefox.settings.services.mozilla.com to 162.248.241.94
Mar 14 02:14:20 dnsmasq[3216]: 71700 127.0.0.1/38951 forwarded firefox.settings.services.mozilla.com to 66.187.76.168
...order of calls is reversed in log lines!
I got rid of systemd-resolved to rely on dnsmasq.

tftp retry timeout exceeded

My issue is retry count exceeds when I download kernel image to Econa processor board (Econa is ARM based processor) via TFTP as shown below
CNS3000 # tftp 0x4000000 bootpImage.cns3420.uclibc
MAC PORT 0 : Initialize bcm53115M
MAC PORT 2 : Initialize RTL8211
TFTP from server 192.168.0.219; our IP address is 192.168.0.112
Filename 'bootpImage.cns3420.uclibc'.
Load address: 0x4000000
Loading: T T T T T T T T T T
Retry count exceeded; starting again
Following are the points which may help you in finding the cause of this error.
Ping response is OK
CNS3000 # ping 192.168.0.219
MAC PORT 0 : Initialize bcm53115M
MAC PORT 2 : Initialize RTL8211
host 192.168.0.219 is alive
When I tried to verify TFTP is running, I tried as shown below. It seems TFTP server is working. I placed a small file in /tftpboot:
# echo "Hello, embedded world" > /tftpboot/hello.txt"
Then I did localhost
# tftp localhost
tftp> get hello.txt
Received 23 bytes in 0.1 seconds
tftp> quit
Please note that there is no firewall or SELinux on my machine.
Please verify location of these files are OK. I have placed kernel image file bootpImage.cns3420.uclibc in /tftpbootTFTP service file is located in /etc/xinetd.d/tftp.
My TFTP service file is:
service tftp
{
socket_type =dgram
protocol=udp
wait=yes
user=root
server=/usr/sbin/in.tftpd
server_args=-s /tftpboot -b 512
disable=no
per_source=11
cps=100 2
flags=ipv4
}
printenv response in U-boot is:
CNS3000 # printenv
bootargs=root=/dev/mtdblock0 mem=256M console=ttyS0
baudrate=38400
ethaddr=00:53:43:4F:54:54
netmask=255.255.0.0
tftp_bsize=512
udp_frag_size=512
mmc_init=mmcinit
loading=fatload mmc 0 0x4000000 bootpimage-82511
running=go 0x4000000
bootcmd=run mmc_init;run loading;run running
serverip=192.168.0.219
ipaddr=192.168.0.112
bootdelay=5
port=1
bootfile=/tftpboot/bootpImage.cns3420.uclibcl
stdin=serial
stdout=serial
stderr=serial
verify=n
Environment size: 437/4092 bytes
Regards
Waqas
Loading: T T T T T T T T T T
Means there is no transfer at all; this can be caused by wrong interface setting i.e.
u-boot is configured for 100Mbit full duplex, and you try to connect via half duplex or 10Mbit (or some mix of it). Another point is the MTU size, should be 1500 (u-boot cannot handle packet fragmentation)
Hint for windows/vmware users:
tftp timeouts from u-boot are caused by windows ip-forwarding.
1) If you have a home network : switch it of.
2) You are running Routing and Remote Access service : shut down service
3) check registry for ip forwarding:
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters\IPEnableRouter
set value to 0 (and maybe reboot)