TCP-IP_Beta1

Looking at the new internet tools, what is ipvars meant to do? All the other ones respond to -help, but this one doesn’t.

Ignore, I was looking at the RODev one, not the ROOL one… 🤦

Ah, it looks like it does what I thought, going by the name.
It sets up various system variables.

https://gitlab.riscosopen.org/RiscOS/Sources/SystemRes/InetRes/-/blob/master/Sources/ipvars/c/ipvars

Some interface specific variables are created.

From the new IPVars on a Titanium :-

*RAM::RamDisc0.$.IPVars
*show inet$ecp*
Inet$ecp0$Addr : 192.168.1.207
Inet$ecp0$Broadcast : 192.168.1.255
Inet$ecp0$Host : 0.0.0.207
Inet$ecp0$MAC : aa.bb.cc.dd.ee.fe
Inet$ecp0$Mask : 255.255.255.0
Inet$ecp0$Network : 192.168.1.0
Inet$ecp1$MAC : aa.bb.cc.dd.ee.ff
**show inet$lo0*
Inet$lo0$Addr : 127.0.0.1
Inet$lo0$Broadcast : 127.255.255.255
Inet$lo0$Host : 0.0.0.1
Inet$lo0$Mask : 255.0.0.0
Inet$lo0$Network : 127.0.0.0
*

That looks like a simplistic version of the ancient SetInetVars command I wrote some years ago, which can be found in my old archives…

https://usenet.gerph.org/Internet/ as BasicExamples.zip

I’ve extracted SetInetVars here in case anyone wants to use that – I assume it still works, although it does read the routing table using the KVM operations which aren’t really guaranteed.

https://gitlab.gerph.org/-/snippets/27

I’ve updated my ancient script to support reading IPv6 addresses as well.

https://gitlab.gerph.org/-/snippets/28

Output looks like this:

charles@phonewave ~/projects/RO/pyromaniac (pwmdriverpca9685-experiment)> pyrodev --command setinetvars --command 'show Inet$*' 
Program renumbered
Inet$awdl0$IP6 : FE80:0:0:0:608E:77FF:FE88:6D4
Inet$en0$Broadcast : 192.168.0.255
Inet$en0$Domain : gerph.org
Inet$en0$HostName : phonewave
Inet$en0$IP : 192.168.0.98
Inet$en0$IP6 : FE80:0:0:0:107C:D96F:3107:ADA0
Inet$EtherDomain : gerph.org
Inet$EtherHostName : phonewave
Inet$EtherIP : 192.168.0.98
Inet$EtherIPAddr : 192.168.0.98
Inet$Hostname : localhost
Inet$llw0$IP6 : FE80:0:0:0:608E:77FF:FE88:6D4
Inet$lo0$HostName : localhost
Inet$lo0$IP : 127.0.0.1
Inet$lo0$IP6 : 0:0:0:0:0:0:0:1
Inet$lo0$RemoteIP : 127.0.0.1
Inet$LocalAddr : 0100007F
Inet$LocalHostName : localhost
Inet$LocalIP : 127.0.0.1
Inet$LocalIP6 : 0:0:0:0:0:0:0:1
Inet$LocalIPAddr : 127.0.0.1
Inet$LocalIPRemoteAddr : 127.0.0.1
Inet$utun0$IP6 : FE80:0:0:0:774C:5B2:B888:68C2
Inet$utun1$IP6 : FE80:0:0:0:DDD7:98CF:AFD4:D7A6

There is an incompatibility between the new lib and the ROD Resolver.

ROD Resolver_GetAddrInfoAsync seems to follow the classical Linux format:
struct addrinfo {
int ai_flags;
int ai_family;
int ai_socktype;
int ai_protocol;
socklen_t ai_addrlen;
struct sockaddr *ai_addr;
char *ai_canonname;
struct addrinfo *ai_next;
};

in the TCP-IPBeta1, the the order of elements ai_addr and ai_canonname are inversed.

Same order with bsd, it’s a POSIX definition.
https://man.openbsd.org/getaddrinfo.3

Have you raised a bug report?

Incidentally… it would be nice if Resolver could handle DNS-SD and the ability to look up SRV records (that is to say, given “thisthingy.local”, to return an IP address and a port).
These are, by the way, standard modern DNS behaviours… I can dream, right? ;)

The <netdb.h> header shall define the addrinfo structure, which shall include at least the following members:

int               ai_flags      Input flags. 
int               ai_family     Address family of socket. 
int               ai_socktype   Socket type. 
int               ai_protocol   Protocol of socket. 
socklen_t         ai_addrlen    Length of socket address. 
struct sockaddr  *ai_addr       Socket address of socket. 
char             *ai_canonname  Canonical name of service location. 
struct addrinfo  *ai_next       Pointer to next in list. 

Doesn’t specify that they are in that order though?

Although it would be rather helpful if they stayed in the same order as before on our platform…

Doesn’t specify, but usually when a struct is defined, it’s listed as defined (useful for those using BASIC!).

See also RFC 3493, so non-compliance would be a peculiar, and potentially problematic (if applications built from different headers gave the struct as having data in different places).

Doesn’t specify, but usually when a struct is defined, it’s listed as defined (useful for those using BASIC!).

My guess is that the POSIX people assume that you’ll be using C and will be using the OS-provided headers, and therefore – at least in theory – don’t care what order the members are in.