home devices and related

One way to view requirements for a network is by functional groups, connections, and security levels.

groups, connections, security/safety

• guests: LAN parties, family, push devices (weather smart mirror). internet, multiple WAP's, loose firewall, exception reports
• office active: browsing, file sharing, editing, backup. expandable CAT-5, internet firewalled strongest security and devices limited by physical ID
• office archive: SSD's or HDD array. No internet or OS. Photos, scans, texts, docs, receipts, tax, possible some cloud
• media playback: PON or GPON. No internet, OS update server by USB tethered phone. One or two terminals with one server to many displays and speakers.
• security/safety: blend PON, CAT-6 PoE, possibly CAT-5. No internet, OS update server by USB tethered phone. Device ID only, cams, device logging, dedicated storage and backup.
• smart home network: No internet, update server by USB tethered phone. CAT-5,6, or PON. Device ID only, some storage, database
• expansion: possible home business dedicated

For OS, Linux is desirable in all of these, although some gaming devices will obviously not be partial. In all cases, we seek to minimize the the use of WiFi (data security) and internet access. For any outdoor nodes (security cams, sensors), we'd prefer fiber-optic (lightning surge, physical security).

sample vid (sample) sample, 2026.

hotspot the phone :: 4G->5G transition

"...I would forgo a separate hotspot device unless I needed if for group internet access. Buy more data for the phone and USB-tether."

NB: for usb-tethering a camera, either in a phone or as an independent cam, go here.

---

5G rolled out in July for T-Mobile. At that time, my phone's data plan began to include a free 40G of 5G "hotspot" data. This additional feature allows a person the option to use their phone as a WiFi hub. They can still access the Web through their phones' browser (the old way), but they can also broadcast the signal like a hub. A software toggle in the phone's settings (see below) turns it on or off.

Transmitting WiFi creates a hot phone, and heat is the number 1 electronics killer. When I saw how hot the phone was getting, I purchased another device (plus another number), that's solely for hotspotting. I have too much contact info and so on in my phone for me to deal with it failing due to hotspotting heat.

Of course, as soon as I purchased the dedicated hotspot device, I found-out that it wasn't really necessary. I learned I could use the phone without WiFi heat problems... if I physically tethered it using a USB cable (pic below) instead of running WiFi. In addition to less heat (a fifth of the heat), the cable charged the phone during internet use. The connection also is less hackable than WiFi.

The drawback is that a physical connection only can be attached to one device. But could a person allow multiple connections by tethering to a switch, or a router? Haven't yet attempted.

data expense on separate hotspot

I had already purchased a hotpsot device -- basically a data connection device with no calling, text or apps on it -- so I went on to purchase a $10 a month data plan for it and configured it (see further down). Data is quintuple the price of phone plans. It's possible providers don't receive enough intel from that device to sell/provide to advertisers/LEA's, or that it's considered generally a business device, or that they don't receive subsidies from Google, etc? Whatever the cause, $10 per month bought me 2GB and no rollover.

---

configuration

First though, three questions answered that I wish I could have easily found on Google.

1. Is a separate SIM needed for the dedicated mobile device? Yes. Although a person could physically move their phone SIM into the dedicated hotspot, both the phone and the dedicated hotspot device have unique IMEI's. So the phone provider will have to register and unregister the device each move of the SIM. This is liable to lead to interruptions, in addition to the liklihood of damaging the SIM during repeated transfers. However, a separate SIM *does* mean a separate phone number with its own data plan. More below.

2. With 2 SIMS, do hotspot minutes from one device merge with the other device? No. Even though users receive one bill, it has two numbers with two separate data plans. Overage charges would apply if I went over on one device but still had gigabytes left on the other device. Further, dedicated hotspot device minutes are expensive: $10 per month on the device got me 5Gigs of 5G speed data and unlimited 126K data, LOL.

3. Which dedicated hotspot is a good choice? Don't buy one: USB tether from your phone. If buying anyway, check the phone provider's website for compatible devices, then buy one inexpensively refurbished from say, EBay. Example: I'm on T-Mobile and the T-Mobile website sells Inseego and Franklin hotspots. The Franklin T10's are $30 refurbed, but they transmit data at 4G speeds. This is a waste of $$. The 5G Inseego M2000 (pictured) is $340 new from T-Mobile. I bought one for $110 off EBay. Works and charges fine.

configurations

Four sections below: phone WiFi, phone tether, and dedicated hotspot. Each requires a configuration file: an /etc/udev/rules.d/ file (tether) , and a wpa_supplicant.conf file (WiFi).

Part 1: phone hotspotting

It may overheat, but the phone can provide internet 3 ways. bluetooth, wifi, or USB cable tethered. The bluetooth is too insecure to bother with. That leaves:

1. Wifi hotspot: enable/disable in phone Settings as needed. Connect several devices with ESSID and password. If neighbors or wardialer squat it, can WAP it and/or hide the ESSID. /etc/wpa_supplicant/
2. USB tether: enable/disable in phone Settings as needed. Connect as ethernet (no pass) to single device. Cooler than WiFi, more secure than WiFi, charges while connected. Set this up, even if it's not needed. /etc/udev/rules.d/

BTW, USB tethering can also be configured for reverse-tethering - taking internet from one's connected laptop and sending it to the phone. Not sure when this would be useful, but it's available.

1a. Wifi hotspot

This is the simpler of the two, but more open to hacking. No configuration of the laptop/desktop is required -- the phone becomes another Wifi connection point, and the user connects their laptop to it like they would any other Wifi router/source.

1a. use (WiFi)

• Settings --> Connection & sharing --> Mobile hotspot (slider). Once enabled, a hotspot icon appears in the upper R, near the 5G reception bars.

• # wpa_supplicant -D wext -i wlan0 -c /etc/wpa_supplicant/wpa_supplicant.conf &

• # dhcpcd wlan0

1a. setup (WiFi)

• Settings --> Connection & sharing --> Mobile hotspot (slider). Tapping on Mobile Hotspot will allow a person to change the ESSID name, hide it, change the password, the security, etc.
  
  Save after all are set

• $ wpa_passphrase [ESSID] [password]

• # nano /etc/wpa_supplicant/configfile.conf

  Put in the info from passphrase. The line scan_ssid=1 is necessary if hiding the ESSID. For security, key_mgmt=WPA-PSK is standard.

• # chmod +x /etc/wpa_supplicant/configfile.conf

1b. use (USB tether)

Android tether page (Arch). Tethering is slightly more complicated than Wifi for the initial setup, because configuring on the desktop/laptop is needed. Worth it.

tether use

• Connect USB cable
• On the Android, doesn't matter USB mode, but move slider below to right to enable tethering
  
• On the laptop/desktop:

  # dhcpcd enp0s21d0u2

1c. setup (USB tether)

Linux desktops/laptop network connections include loopback, ethernet id, and wifi id. This USB-tethered phone will act like a second ethernet card. The connection becomes added to the list inside /sys/class/net.

• # pacman -S usb_modeswitch android-udev android-tools

  ... can also install openvpn if desired for other options.
• group "adbuser" will have been created, so add the user...

  # nano /etc/group [add user to adbuser]

• phone: attach USB cable and ENABLE USB TETHERING (!) in Settings.
• desktop: check network units already in place. each device will have 3 lines eg, the ethernet:

  $ systemctl list-units |grep net
  sys-devices-pci0000:00-0000:00:1b.6-net-enp0s21b6.device
  loaded active plugged Ethernet Connection I219-LM
  sys-subsystem-net-devices-enp0s21b6.device

• $ lsusb
  Bus 001 Device 012: ID 22d9:276a OPPO Electronics Corp. SM8150-MTP _SN:E18D827E

  the phone contains a different product ID for its internet connection than a basic USB connection; USB TETHERING MUST BE ENABLED in the phone Settings to get a correct product ID. (see next step)
• The kernel will not create a net connection with only a Vendor ID, it must also have the (correct) Product ID:

  # nano /etc/udev/rules.d/90-android-tethering.rules
  # Execute pairing program when appropriate
  ACTION=="add|remove", SUBSYSTEM=="net", ATTR{idVendor}=="22d9", ATTR{idProduct}=="276a", ENV{ID_USB_DRIVER}=="rndis_host", SYMLINK+="android"

• # udevadm control --reload

• now our device identifier should appear on the list. It's unauthorized for a connection yet, but should exist:

  $ systemctl list-units |grep net
  sys-subsystem-net-devices-enp0s21d0u2.device loaded active plugged
  SM8150-MTP__SN:E18D827E

• now that we have its name, I just wrote it down, unplugged and replugged the USB cable and re-enabled tethering and:

  # dhcpcd enp0s21d0u2

  ...then I pinged to verify. Could also do a speed test.

extra: adb command setup

To issue commands into the phone from the connected device using "adb" commands (and not just connect to internet), which is necessary for more complicated things like port forwarding and AziLink...

• get the USD VID from lsusb and then

  # nano /etc/udev/rules.d/51-android.rules
  SUBSYSTEM=="usb", ATTR{idVendor}=="22d9", ATTR{idProduct}=="2765", MODE="0666", OWNER="foo", GROUP="plugdev"

• # udevadm control --reload

• plug USB into phone, enable the file transfer/auto option

• $ adb devices
  List of devices attached
  143cfd76     device

Having this connection for ADB commands seems to heat up a laptop and use memory. Accordingly, I keep the ADB connection turned-off by commenting out the defining line in /etc/udev/rules.d/51-android.rules unless I am going to use adb commands.

Part 2: dedicated device hotspotting

Using the 5G Inseego M2000, we can connect:

1. Wifi hotspot: enable/disable in menu. Connect several devices with ESSID and password. /etc/wpa_supplicant/wpa_supplicant.conf
2. USB tether: enable/disable in menu as needed. Connect as ethernet (no pass) to single device.

Use the embedded website to change the name of the network and its password. When it first arrived, was missing SIM, then SIM arrived by mail from T-Mobile. However, even though device was T-Mobile a call still had to made to unlock it. They never were able to unlock it, even after letters to T-Mobile.

2a. Wifi hotspot

This is the simpler of the two, but more open to hacking. No configuration of the laptop/desktop is required -- the phone becomes another Wifi connection point, and the user connects their laptop to it like they would any other Wifi router/source.

2b. use (WiFi)

• Settings --> Connection & sharing --> Mobile hotspot (slider). Once enabled, a hotspot icon appears in the upper R, near the 5G reception bars.

• # wpa_supplicant -D wext -i wlan0 -c /etc/wpa_supplicant/wpa_supplicant.conf &

• # dhcpcd wlan0

1a. setup (WiFi)

• Settings --> Connection & sharing --> Mobile hotspot (slider). Tapping on Mobile Hotspot will allow a person to change the ESSID name, hide it, change the password, the security, etc.
  
  Save after all are set

• $ wpa_passphrase [ESSID] [password]

• # nano /etc/wpa_supplicant/configfile.conf

  Put in the info from passphrase. The line scan_ssid=1 is necessary if hiding the ESSID. For security, key_mgmt=WPA-PSK is standard.

• # chmod +x /etc/wpa_supplicant/configfile.conf

2c. use (USB-tether)

Android tether page (Arch). Like the phone, we can USB-tether with the dedicated device.

• Connect USB cable
• Unlike the Android, software selects tethering automatically. No adjustments are needed.
• On the laptop/desktop:

  # dhcpcd enp0s16f1u2

2d. setup (USB tether)

Linux desktops/laptop network connections include loopback, ethernet id, and wifi id. This USB-tethered phone will act like a second ethernet card. The connection becomes added to the list inside /sys/class/net.

• # pacman -S usb_modeswitch android-udev android-tools

  ... can also install openvpn if desired for other options.
• group "adbuser" will have been created, so add the user...

  # nano /etc/group [add user to adbuser]

• phone: attach USB cable and ENABLE USB TETHERING (!) in Settings.
• desktop: check network units already in place. each device will have 3 lines eg, the ethernet:

  $ systemctl list-units |grep net
  sys-devices-pci0000:00-0000:00:1b.6-net-enp0s21b6.device
  loaded active plugged Ethernet Connection I219-LM
  sys-subsystem-net-devices-enp0s21b6.device

• $ lsusb
  Bus 001 Device 008: ID 1410:b020 Novatel Wireless M2000

• Edit the udev rule to add the VID information. We can simply add another entry to the file we created for the phone.

  # nano /etc/udev/rules.d/90-android-tethering.rules
  # Execute pairing program when appropriate
  ACTION=="add|remove", SUBSYSTEM=="net", ATTR{idVendor}=="1410", ATTR{idProduct}=="b020", ENV{ID_USB_DRIVER}=="rndis_host", SYMLINK+="android"

• # udevadm control --reload

• now our device identifier should appear on the list. It's unauthorized for a connection yet, but should exist:

  $ systemctl list-units |grep net
  sys-subsystem-net-devices-enp0s16f1u2.device loaded active plugged M2000

• we have its kernel name and can connect with dhcpcd:

  # dhcpcd enp0s16f1u2

  ...then I pinged to verify. Could also do a speed test.

more configuration

This isn't necessary, but a person can visit the manufacturer's site (http://my.mifi) and create an account to access additional functions on the dedicated device. This probably also provides them with additional information to sell advertisers.

Part 3 troubleshooting

m2000 - invalid SIM

3 days after SIM installation, it was still spawning errors. In my online T-Mobile account, device information indicated it was "locked but available for unlock". A call to T-Mobile revealed the m2000 must be on their network 45 days, then corrected and said he could do it. They never did. They devices "locked".

m2000 - dhcpcd errors, no ping.

Strangely, browsing worked OK, but seemed to buffer.

# dhcpcd enp0s16f1u2
dhcpcd-9.4.1 starting
DUID 00:03:42:4D:45:44:01:5E:4C:10:8A:30:C6:C0:4B:46:4A:31
enp0s16f1u2: waiting for carrier
enp0s16f1u2: carrier acquired
enp0s16f1u2: IAID CC:03:11:AC
enp0s16f1u2: adding address C2D0::C6BF:7F13:14C2:1315
enp0s16f1u2: rebinding lease of 192.168.1.2
enp0s16f1u2: probing address 192.168.1.2/24
ps_bpf_recvmsg: Invalid argument
ps_bpf_recvmsg: Invalid argument
ps_bpf_recvmsg: Invalid argument
enp0s16f1u2: leased 192.168.1.2 for 86400 seconds
enp0s16f1u2: adding route to 192.168.1.0/24
enp0s16f1u2: adding default route via 192.168.1.1
ps_bpf_recvmsg: Invalid argument
forked to background, child pid 31249

Is data unlimited, albeit slow? Which one? Where do plans work?

tcpdump in userspace

Many times we'll have inexplicable collisions -- eg 2000ms pings -- on our home LAN. Is someone squatting on our LAN? Is it a configuration problem?

1. squatting

If I'm not at the LAN's router terminal to view the DHCP table...

# nmap -sn --max-rate 100 192.168.1.0/24

Slow-down the rate to 100 to catch cell phones, which otherwise may not have time to respond. The generic 192 net will obviously vary depending on setup.

2. weird collisions

If possible switch from channel 1 on the Wi-Fi of course. And if our client is at the outer range of the router, we'd expect more interference and might have to move things around.

If these are not the causes, we'd want to capture some traffic and review it for suspicious activity. This is not typically trivial. To access traffic, we need to install tcpdump and reconfigure it for user-level execution, so that its files (.PCAP) are easy to manage. Next, we attempt to constrain tcpdump's enormous PCAP captures to a manageable size and format. Finally, we could evaluate the PCAP network data. Let's do the last two first, since many readers already have tcpdump configured.

A. use and constrain PCAP

As usual, StackOverflow closes the most relevant questions as irrelevant, lol. But you can scroll down to bro to see how its done with bro. Wireshark and some others , Zeek are additional options.

Try to pre-simplify by limiting tcpdump. Obviously, tcpdump unhelpfully only outputs to the screen, so a person has to tee its output to a file, let's start there...

The command gets long, but we can get a good PCAP.

time limit

Tcpdump doesn't have an inherent duration flag. Users typically must CTRL-C which can corrupt the output file -- the program was natively designed to STDOUT to the screen. However the "-c" flag tells it how many packets to capture before quitting.

$ tcpdump [other filters] -c -w filename.$(date +%Y-%m-%d.%Z.%H.%M.%S).pcap

B. evaluate PCAP

Problematic areas include

C. configure tcpdump for user

Users must root-up to operate tcpdump as installed:

$ tcpdump
tcpdump: wifi01: You don't have permission to capture on that device

Of course, to see the error messages more completely:

$ strace tcpdump 2>&1 | tee file.txt

after initial setup

Typically problems only occur after a restart and/or an update. The steps for initial setup follow this section and users can refer to those if anything needs to be reset. Otherwise...

1. attempt a user-level simple usage.

   $ tcpdump

2. if all goes well, use the more complex commands discussed in section A.

initial setup

Generally, know which tcpdump location executes, and add the user to any created groups. General instructions.

For location, run $ strace tcpdump and note whether if fails in /bin, /usr/bin, /usr/sbin. For groups, verify inside /etc/group. Then...

1. create pcap group and add the user

   # groupadd pcap
   # usermod -a -G pcap user

2. give pcap group permissions to tcpdump and make it group executable (750). Let's suppose tcpdump executes from /usr/bin.

   # chgrp pcap /usr/bin/tcpdump
   # chmod 750 /usr/bin/tcpdump

3. We modify executable (binary) file capabilities, in this case tcpdump, using setcap. The specified group, (not just root) can then operate the wifi in promiscuous mode.

   # setcap cap_net_raw,cap_net_admin=eip /usr/bin/tcpdump

4. Verify the binary capabilities were updated

   $ getcap /usr/bin/tcpdump
   /usr/bin/tcpdump cap_net_admin,cap_net_raw=eip

problems

There can be other permission problems. The initial problem is user permission to the wifi device. That is handled above. A secondary problem is user access to run tcpdump. This gives the following failure.

$ tcpdump
bash: /usr/bin/tcpdump: Permission denied

One site adds this line to ensure tcpdump is receiving root access for the user. Suppose we verify by strace that our execution of tcpdump is from /usr/bin/tcpdump. His would be...

# groupadd tcpdump
# usermod -a -G tcpdump user
# chown root.tcpdump /usr/bin/tcpdump
# chmod 0750 /usr/sbin/tcpdump
# setcap cap_net_raw,cap_net_admin=eip /usr/bin/tcpdump

last resort

If everything is set, getcap is returning everything proper and the error still appears, we can change the execution from group level only (750), and add it to the user also (755). I consider this a last resort because, at that point, there is essentially zero security on the wifi card. However, a person could run 755 when they want to run wireshark or some such and

stop changing sh*t...

...just STOP.

We choose Linux because we like a stable OS we rarely have to upgrade or alter. But that's becoming more and more difficult. Unless I've overlooked something, even simple utilities are eventually "improved".

The latest is a bedrock of operation; dhcpcd. This has been a great application and whomever designed dhcpcd has my thanks. Unfortunately, it now appears to have been "upgraded".

ctrl_interface not defined in $wpa_supplicant_conf
not interacting with wpa_supplicant(8)

In other words, we have an unnecessary new level of dhcpcd specificity when dhcpcd initializes, because it will also seek to initialize wpa_supplicant. Apparently for that reason, the dhcpcd developer decided that the wpa_supplicant.conf file was fair game for him or her to use in a new way. So now he/she requires us to hand-enter ctrl_interface information into wpa_supplicant.conf. If we don't add this ctrl_interface line, dhcpcd is unhappy and fails. No DHCP lease. Brilliant.

This moron also failed an even more basic observation: that wpa_supplicant has its own independent initialization process which relies, appropriately, on /etc/wpa_supplicant.conf. During its initialization, if wpa_supplicant encounters the ctrl_interface line which dhcpcd required us to add, wpa_supplicant reads the line as an error, and exits. Bingo, Catch-22. If I don't modify the config file, I can't negotiate a DHCP lease. If do modify the config file, wpa_supplicant fails. I guess we didn't want to use our wireless cards anyway.

Developers, please just STOP upgrading utilities we rely upon and which have no need for upgrade. Please. And if you're going to do something creative anyway, AT LEAST generate a separate configuration file.

more ipv6 / ipv4 fun

Links: ipv6 over adsl :: Linksys E1000 knowledge base :: Linksys list of IPv6 enabled

www.southparkstudios.com is a useful site for checking IPv6 functionality. YouTube, probably due its fallback capacities (PPAP, HTML 5) is much more tolerant. So it was of interest to recently that I could access South Park at the gf's place, but not at home.

home setup

At home, we have ATT ADSL split between roommates. Service was initiated during the years when ATT provided Linksys E1000 routers in tandem with Motorola 2210-02 modems. This equipment is questionable; the Motorola overheats if it's breathed on, and the Linksys has no IPv6 support. This post is about the latter.

To set-up IPv6, we only want one IPv6 choke-point, so we want the modem to pass everything (bridge mode) and do the PPoE inside the router. But can we get the E1000 to do IPv6? Appears not easily.

Step 1 - ISP

Contact with ATT today noted that their DNS servers are resolving in IPv6.

Step 2 - Modem and Router

Modem is not in bridge mode; it's providing DHCP downstream to the LAN (E1000 Router). Unclear whether that's already degraded or filtered to IPv4-only coming from modem. Also it appears that the modem cannot be set to bridge mode without physical modification.

The router itself is not inherently IPv6 capable, so it may be worthwhile to start there. ATT sells the IPv6 Motorola NVG510 modem/router combo for $100. That one's not been getting good reviews. Another option is say, the less expensive D-Link G604T ($60). Outdated, but OpenWRT or DD-WRT should handle things.

E3000 v.2.1 (dd-wrt)

In an attempt to enable IPv6, installed dd-wrt software. Apparently the E3000 has a small (4MB) memory capacity so we're only looking for K2.6 builds, which run about 3.3MB. It was also suggested to keep Tx power down around 45mW for best throughput. I'll probably set my MTU filter at 1500 or 1400. We'll see.

Couple of useful links:

page 4 describes 16964 as first build supporting the router, then the 16968 build as stable, then 16994 (nokaid) having ipv6. 19519 may be most recent, but appears best to start with 16968 and then flash up to 19519 (nokaid).

firewall code

FAIL: Slackware 12.0 - NFS, NAS, rsync

Links:

---

I created an NFS Ethernet with a 4 port router. One of the ports went to a NAS, another to a printer, a third to my desktop and fourth was left free. The point was a LAN which allowed me to use the NAS as a central synch point, something like a cloud server. First, I would synch with my desktop, secondly, when I arrived home with a work laptop, I could plug it into the open router port and synch that also.

NFS was because it's an older service built upon Sun's RPC services -- it's tried and true. Additionally, my systems currently are Linux systems, so why add security and memory problems with SMB or Samba? Ultimately however, I was defeated by a sh*tty NAS enclosure.

Vantec LX NAS (NST-375LX-BK)

I purchased a Vantec NAS enclosure and ran into problems immediately, probably because I didn't research the product in advance. Thinking it would work generically, I installed a dormant 350GB PATA drive into the Vantec. The enclosure has USB and Ethernet ports, but it appears Vantec's brilliant designers made the Ethernet firmware Microsoft protocol exclusive. This meant it was not native NFS and would instead require SMB (Samba). I was faced with installing Windows compatible Samba garbage or using the USB connection. In addition to no network compatibility (except samba), USB speeds are similar to molasses. What a load of crap. For those who want to jeopardize your box w/Samba, here is a forum link with the info of what to do.

Edit: the power conditioning in this box is just a voltage regulator chip; even normal line transients will change power to the enclosed HDD and possibly zorch the data. After I gave up on this box as a NAS, I used it as an external back-up and lost about 100G of data, some of it irreplaceable, eg family photos. I now use only USB powered externals.

politics

A short digression for a rant. Following my above situation, I looked for other options. There is a hideous lack of home-user NAS enclosures running NFS in the US consumer marketplace. In the US, to purchase a NAS that works with NFS one must spend at business levels, about $1000. Interestingly, if one only needs a Windows enclosure, the cost is perhaps $400. Meanwhile, there are many options for inexpensive NFS-serving NAS enclosures in foreign markets, such as the UK. These foreign markets don't require Windows or Samba, so why is NFS so shut-out in the US? Especially when it's understood that Windows and Samba have security vulnerabilities. One has to ask themselves what marketplace and/or government influences would lead to such a situation. Interesting.

NFS, RPC, portmap

Without an NFS box, let's still take a look at what I would have done, if I'd had one. As noted above, NFS lies on top of RPC services. RPC ports are not dedicated, they move around, so we need port mapper as a connection tracker. The portion of NFS which sends commands and acknowledgments between server and client is a normal dedicated port "file" (ports are files in UNIX), port 2049. But NFS uses undedicated RPC ports to move the data payloads, eg. the powerpoint files, the text files, whatever we are moving. The portmap application is necessary for this portion of the transfer. If portmap crashes, data may be lost or unsaved. To see what ports portmap is currently tracking, use, eg...

$ rpcinfo -p

RPC functionality

This tutorial is a good start to setting up the RPC functionality necessary for NFS.
1. The presence of /etc/hosts.allow and /etc/hosts.deny.

portmapper functionality

NFS functionality

1. In function, I've seen that domains have to be the same across the machines. For example, let's say one machine's /etc/HOSTNAME indicates "green.example.net", and another machine on the same LAN has "blue.example.net". This makes the situation very difficult.

NFS from command line

NFS is essentially a mount, but remote - we mount a drive, or folders from a drive, from another system on the LAN, and it appears as a drive on our current system, though labeled so we know it's an NFS share. We can mount temporarily from command line or make it permanent as part of the boot process.

NFS as an fstab line

NFS directory mounting

security

NFS requires various ports. The system should be operating smoothly before attempting to add firewall functionality because ports may be affected from the firewall rules. If anything goes wrong, we will know that it was on the firewall side, and not our NFS configuration.

Slackware 12.0 - Dual Homed

Challenges can arise when a wifi NIC is handling wifi internet access and, in the same computer or "host", an ethernet NIC is operating in a wired LAN (eg, with a printer and backup storage). Since the host exists in two different LANs simultaneously, it is "dual homed". Obviously, two LANS means two routers.

gateway vs. dhcpcd

Check email at Yahoo. The host PC makes this request to Yahoo and Yahoo is outside the host's network, so it needs to use the gateway and the name servers outside the gateway. But when interfaces are being initialized at boot, the dhcp application, dhcpcd, overwrites the /etc/resolve.conf file that shows the IP addresses of these nameservers. So, if we bring the eth0 connection up after the wlan0 connection, our nameservers will be overwritten. To avoid this we do all these things:

/etc/rc.d/rc.local
ifconfig eth0 down
ifconfig wlan0 up
dhcpcd wlan0
sleep 3
route
sleep 5
route del -net 169.254.0.0 netmask 255.255.0.0 dev wlan0
ifconfig eth0 up
sleep 3
dhcpcd -R eth0 #-R prevents resolv.conf overwrite
sleep 3

Sometimes,(rare) I have a "UG" default gateway for both wlan0 and eth0 even after these steps. I then remove the extra gateway at the command line:

route del default eth0

A quick verification with "route" shows me the second gateway is gone.
Also there are these files...

loading order

rc.inet1 reads rc.inet1.conf and loads rc.wireless which reads rc.wireless.conf when loading. I don't worry about the rc.wireless.conf, but, in rc.inet1.conf I look for the default gateway line and I change it from "" to the IP of the gateway router.

security

The final step. We want to be sure everything is running before we lock down ports.

Slackware 12.0 - SiS190 eth0 module

Links: sis191 instructions

---

symptoms

I connect a hard-wire Cat5 cable from my box (integrated SiS190 NIC) to a known-good Cisco router. Dhcpcd times-out and assigns a default IPV4LL address, eg 169.254.126.11. The network is unreachable. Is it the cable, the router, the NIC, router firmware, OS software?

Unfortunately for my weekend, several hours pass narrowing the options. Eventually, it appears the insertable module for the NIC is from 5/2007 and does nothing. Isn't that nice? The process is explained relatively well here.

Kernel recompiling was required. Since I had no Net on this box, I had to download kernel source on another box and sneaker-net it to the box with SiS191.