The reality is, if you don't involve someone from IT, you have a very high likelihood of causing problems for both yourself and others. IT can't necessarily do all the work here, but they should definitely be involved in the discussion. If nothing else, they should be helping decide which route (sic) to go. Using a DHCP address someone else might use will piss off the affected user and IT when they have to chase it down. Finding a router to unexpected networks will piss off IT, as will having rogue wifi spots. It's just all around better to involve IT.
If an IT group is as Konstantin as you describe, there is something wrong.
I spent 20+ years as a software engineer, and the last 15 or so in IT roles supporting all sorts of engineers so I know both sides.

On 03/31/2017 12:53 PM, Konstantin Olchanski wrote:
On Fri, Mar 31, 2017 at 07:40:15AM -0400, James M. Pulver wrote:
Shouldn't we all take a step back here and ask why your IT support
isn't providing the resources you need to run the experiment?


Cue-in the usual "expectation vs reality" meme.

The reality of IT support is you open a helpdesk ticket and they close
it with 2 answers "you are not permitted to do this" or "we do not support
what you are trying to do".

The actual reality of IT support is they do not have 100 network engineers
sitting around doing nothing (think firemen at the fire station)
waiting for your request, ready and eager to jump in and help you.
Even if IT department has people who can understand and implement
special non-standard unusual things, such people are usually
super busy and overworked. Good luck getting their attention
and a piece of their time.

As they say, salvation of the drowning is the responsibility of the drowning.

So we all should better learn how to swim. This is why this place is generally
very supportive to people like the guy with the present request/question.


K.O.


I certainly would not want a user to set up an ad-hoc linux router
that they didn't really understand, and hook that to my network. I
also wouldn't want WiFi interference from an ad hoc wifi access
point potentially causing issues with users of the IT wifi service.

All that "big picture" stuff set aside, it's not obvious to me if
you can do this without either IT help or a local router and DHCP
server, because at least for me, most Android tablets assume DHCP -
I don't even know if I can manually set an IP address. I also don't
know - can this unified remote product connect to a bare IP address,
does it use broadcasts to find the server, do they use a cloud
service in the background?

Again, if you're at home and want to play around with this, I think
you can use the instructions here to potentially get it going. At
work? I'd seriously make sure I'm not going to interact with the
production network and cause a lot of unhappy people accidentally
(accidential rogue DHCP server, incorrect routing broadcasts, wifi
to nowhere or wifi interference depending on location, wifi range,
configuration etc).


James Pulver
CLASSE Computer Group
Cornell University

On 03/30/2017 04:50 PM, David Sommerseth wrote:
On 30/03/17 22:22, Brown, Christopher A wrote:
Hi David,


On 03/30/2017 04:03 PM, David Sommerseth wrote:
On 30/03/17 20:53, Brown, Christopher A wrote:
Hi list users,

I am not a network administrator and know only a little bit about the
topic. I need to set up a switch in my lab, so that I can have a wifi
access point and an SL7 desktop computer on the same network, as I need
to be able to connect to the pc using a tablet. My administrator does
not allow switches to be on the network, so I need two network adapters
on my desktop, one for internet, and on on the local switch.

I tried a nominal setup at home first, with my home wifi access point,
router/switch and using only a single adapter. I managed to open the
required ports using firewalld, and my setup works great at home, where
I can connect a tablet over wifi and access my desktop as I need. The
only problem I see there is that the ports I opened are open to the
world, but since that was temporary for testing, it was fine. They are
now closed.

I bought a usb ethernet adapter, which shows up as a network interface
on my lab computer. I now need to configure my lab computer as follows.
I would like the onboard network adapter to be the default (used for web
browsing etc), and use default settings (public zone, etc). And I would
like the new usb network adapter to have the required ports open, so
that I can access that computer over wifi with my local switch.

As I said, I have used firewall-cmd to open and close ports. I know a
little bit, but not enough to accomplish what I describe above.

Can anyone help with this? Just let me know if more information is needed.
As you are not allowed to add a switch on your network, I do not
recommend a bridged setup, where the "internet" interface you already
have is joined together with the USB ethernet adapter.  This would in
effect function just like a switch managed by the Linux kernel.

So you basically need configure your computer as a router.  There are a
few steps needed to manage this.
I don't think I explained my needs clearly. I don't need the tablet to
have internet access, only to have  access to the pc. So I don't (think
I) need the pc to be a router. I just need it to be accessible by the
tablet. I am using an android app called unified remote to access the
pc, and there is a server app to install on the pc. The tablet will
control experiments that will be running on the pc. That is the only
access the table will need. I was hoping that by using two network
interfaces, I could still access the internet from the pc as normal with
the second interface.
Ahh, in that case you can skip step 1) and 2), the rest is basically the
same.  You will however need to do something with the "option
domain-name-servers" in the dhcpd.conf (try removing it).  Then you need
to use IP addresses to connect to your computer, using 192.168.33.1.


David S.




1) Enable IP forwarding.  This is done through sysctl.  To make it
persistent you need to add the following setting into a file in
/etc/sysctl.d (or just update the 99-sysctl.conf).

     # sysctl net.ipv4.ip_forward=1


2) Enable firewalling and NAT.  You mention you've looked at
firewall-cmd.  My experience with that tool in a routing/gateway setup
is not too ideall.  But you need a few iptables rules.  I will let you
figure out how to do this via firewall-cmd.

I will here presume your "internet" NIC is named eth0 and your USB
interface is named usb0.  I also presume usb0 is given the IP address
192.168.33.1/24.

     # Allow traffic to be initiated from the USB interface to
     # anywhere else.  And allow established connections to
     # flow freely and unrestricted.
     # iptables -I FORWARD -i usb0 -m conntrack --ctstate NEW \
                -j ACCEPT
     # iptables -I FORWARD -m conntrack --ctstate RELATED,ESTABLISHED \
               -j ACCEPT

     # Enable NAT for the usb0 interface, restrict the NAT to
     # the 192.168.33.0/24 subnet
     # iptables -t nat -I POSTROUTING -o eth0 -s 192.168.33.0/24 \
                -j MASQUERADE

This masquerading will make all your devices connected to usb0 look like
they are coming from your "internet connected computer".

These rules will be wiped upon boot, so it is important you find a way
how to make this persistent and activated at boot.  On my SL/RHEL based
firewalls, I don't use firewalld but have installed iptables-services
which brings back the old iptables tools (so you can do: service
iptables save).  But be careful using iptables-services and firewalld at
the same time - they will interfere with each other.  (On
non-firewalls/gateways/routers, I use only firewalld - which works fine
in those roles)


3) Configure the usb0 interface ... this is done through NetworkManager
tools or /etc/sysconfig/network-scripts/ifcfg-usb0.  For a minimal
ifcfg-usb0 file you need something like:

      DEVICE="usb0"
      TYPE="Ethernet"
      ONBOOT="yes"
      NOZEROCONF="yes"
      HWADDR="xx:xx:xx:xx:xx:xx"
      BOOTPROTO="static"
      IPADDR="192.168.33.1"
      PREFIX="24"
      NAME="usb0"

See /usr/share/doc/initscripts-*/sysconfig.txt for more information
about these sysconfig files.


4) (optional) Configure a DHCP server to serve on usb0.  This enables
automatic network configuration of your clients connected to usb0.
Without this, you need to resort to manually configuring each device.

I like dhcpd, as that's what I've become used too.  But dnsmasq can also
do this job well.

A very simple dhcpd.conf can be something like this:

     ddns-update-style none;
     authoritative;
     group {
          option routers 192.168.33.1;
          option domain-name-servers 8.8.8.8;

          subnet 192.168.33.0 netmask 255.255.255.0 {
                range 192.168.33.100 92.168.33.199;
                default-lease-time 86400;
          }
     }

(this config is not tested, just something put together on-the-fly).
See more details in /etc/sysconfig/dhcpd too.

Be careful not to start dhcpd listening and responding to DHCP requests
on your internet interface, that will make a lot of users complain.  But
unless the "subnet" section does not overlap with a subnet on your
"internet" interface, you should be safe.

Then it is just to start the dhcpd service.

     # systemctl start dhcpd


This should in most cases get you started.  And again, I have not tested
this exact example - it is pulled together on-the-fly now for this
e-mail.  There might be silly mistakes or other kinds of typos here.




--
Miles O'Neal
CAD Systems Engineer
Cirrus Logic | cirrus.com | 1.512.851.4659

Reply via email to