mike1813
commented
1 month ago Addressed by altering the construction patterns for routes into and out of USB or Bluetooth pairs (i.e., L1 subnets) via gateway hosts connected to L2 or L3 subnets.
This raises an issue on how to control which type of route is created in each case. The solution adopted is to add a prohibited Logical Segment node to every segment inference pattern. This ensures no segment is created if one was created by an earlier pattern. The sequence of patterns then determines which pattern will get to create the segment in each case.
To make this work consistently and continue working even if later patterns are made more general, the prohibited node has been added to every such pattern, not just those concerned with routes into and out of with L1 subnets. Specifically, they are now also used in patterns for routing between L1 subnets (i.e., mesh routing over Bluetooth or routing via a USB hub), and routing between L3 subnets.
Prohibited nodes were previously added to cellular network route inference patterns in changes to address issue #152.
If two hosts are connected or 'paired' via USB or Bluetooth, and one of the hosts also has an interface to some other subnet, it is possible for the other to use the interface. This arrangement is commonly supported by smartphones, where it was often referred to as connection 'tethering'.
In principle, tethering between paired hosts may be used in either direction. For example, consider a smartphone paired with a PC, where the smartphone is connected to a public cellular network. The two hosts can use:
We model the USB or Bluetooth pairing connection as a 1-to-1 subnet. In forward and reverse tethering, the supporting device provides network address translation (NAT) from the USB/Bluetooth 'subnet' (which does not use IP addresses) to the IP subnet. This means there should be a NATSegment representing the route out of the USB/Bluetooth subnet. In practice, one should use a subclasses of NATSegment, because it may have different controls, e.g., 'disable tethering', rather than 'FW Block'.
It is unclear whether it should be possible to make connections back into the USB/Bluetooth subnet. In principle it is possible to run a connection forwarding proxy on one of the paired hosts allowing requests from other connected subnets to be routed via the USB/Bluetooth connection.
In practice this is not done. Where proxies are used, they are specialised to one purpose. For example, suppose a PC connected to an IP subnet is also paired with a USB drive. If the PC runs a file server for clients on the IP subnet, it can enable access to the files stored on the USB drive. However, requests from the IP subnet would not just be forwarded to the USB drive. Instead, the file service would decode the request and make a separate request via the O/S to access data from the USB drive. Similarly, one cannot access services running on a PC via a paired phone. For this reason, in most cases one should use a ClosedSegment for the route into the USB/Bluetooth subnet. If specific USB/Bluetooth devices do provide transparent connection forwarding, then the segment would be a subclass of DeNATSegment.
In the current domain model v6a6-1-2, there are some errors in the type of LogicalSegment inserted.