Talk:Netifrc

Note
Before creating a discussion or leaving a comment, please read about using talk pages. To create a new discussion, click here. Comments on an existing discussion should be signed using ~~~~:

A comment [[User:Larry|Larry]] 13:52, 13 May 2024 (UTC)
: A reply [[User:Sally|Sally]] 11:30, 5 November 2024 (UTC)
:: Your reply ~~~~

Additional section for finding network names

Talk status

This discussion is done.

A section should be added on how to find out what the network interface names are, maybe to run dmesg | grep -i 'network interface'. — The preceding unsigned comment was added by Charles17 (talk • contribs) 07:10, May 12, 2015‎

I added two methods for identifying interfaces. Don't forget to sign your messages on talk pages with your signature. --Maffblaster (talk) 18:36, 12 May 2015 (UTC)

Sorry, I am in doubt if having such section here was a good idea. These information about network interface names seem to be needed in several places, not only here. Especially since udev pushed its "predictable" crap, there are multiple threads on the forums with problems as people don't know about. Of course, most of that trouble is caused by using netifrc at all. But even without using netifrc, this knowledge about the network interface names could be needed, e.g. for setting a static IP address per interface without using the gui. I think a separate article Network interface in Category:Network management might be a better place. There we could collect such information without bloating netifrc, wifi or other articles.

But, what about the "rc-update add net.<interface_name> default" stuff? This is very specific to netifrc and should be mentioned here, see Handbook:Parts/Networking/Introduction, bug #534752.

Regarding "Use curly braces and commas to speed up the process when dealing with multiple interfaces:", why should using syntax instead of typing the path twice be specific for multiple interfaces? --Charles17 (talk) 06:13, 13 May 2015 (UTC)

The ln with curly braces was provided simply as a tip for users creating multiple interfaces in order to save them a bit of typing.. You can use either format; they are both visible in the Handbook. --Maffblaster (talk) 23:48, 17 April 2017 (UTC)

"DHCP is the default behavior ..."

Talk status

This discussion is done as of July 28, 2017.

Please regard this sentence given in the filebox Netifrc#DHCP. Almost everybody can guess what it means. But, could it be reworded something like "The network configuration scripts will use dhcp by default to set up your interfaces. If you need to set up something more ..." and the example shown with some non-default configuration?

As the "behavior" is already default, the example presently shown is useless (even worse in the handbook). Putting dhcp or not doesn't change anything. So why not put a more useful example?

Another thing, regarding /etc/conf.d/net: Wasn't there something saying netifrc should work in some (or more) cases even without setting up the /etc/conf.d/net file? If so, this might be mentioned in Netifrc#Files before before saying "it is created by the system administrator ...".
--Charles17 (talk) 08:05, 28 July 2017 (UTC)

Haha! Charles, I knew you were going to have to say something about this. Did you see my commit message? :P

Even though DHCP is the default behavior I think it is okay to provide an example on how to set DHCP, even if it is the default for netifrc. :) It contrasts the static examples nicely. What is the harm in having an example visibly present? If you want to change the comment, feel free. I just want our users to be able to come to the wiki and view the examples here in this 'parent' article for netifrc.

I'm not sure if there is a place that talks about not setting up the net file, but if there is please add a reference to it and feel free to add additional text. I just didn't want you to completely remove these examples from this article; you can always make what I have added better! Kind regards, --Maffblaster (talk) 16:44, 28 July 2017 (UTC)

Also I should say, I'm totally okay with you 'porting' more examples of netifrc from the Handbook to this article. I actually think it's a good thing if articles outside Handbook cover (in more detail hopefully) the concepts covered in the Handbook. Reason being: the Handbook can't cover everything since it's scope is limited to getting Gentoo running on certain hardware. In fact, I think there is too much covered in the Handbook already; it really shouldn't be the central source of knowledge (on the wiki) for networking with netifrc. If you are not interested in porting it then I will add it to my list of things todo. Let me know via reply here if you're interested. Kind regards, --Maffblaster (talk) 16:57, 28 July 2017 (UTC)

Just found this forum post and if I am not completely misreading it, then users should first try without that file. I think of "normal" computers behind a router providing dhcp. And in case network makes problems, then the conf.d/net file should be created with some useful settings.

And here is an excellent example how youself did handle a Handbook's obsolete proposal: Handbook Talk:Parts/Networking/Wireless

I have too little experience with netifrc and I am not willing to test it again. Putting more useful information here should be done by someone who has better experience with that tool.--Charles17 (talk) 17:56, 28 July 2017 (UTC)

About removing that part from the Handbook, I was trusting what you said about WPA to be accurate. I didn't look myself. I'll ask Roy Bamford (NeddySeagoon) to take a look a this article and fix anything that's not accurate to clear. Kind regards, --Maffblaster (talk) 22:15, 28 July 2017 (UTC)

Solution for captive portals

Hey, I think one thing that’s missing is dealing with captive portals (automatically).

Here in Germany, FRITZ!Boxes are extremely popular, and offer a guest network with a captive portal, so I went and wrote a solution for that, using the lightweight edbrowse (made for blind people):

FILE /usr/local/bin/captive-portalCaptive portal implementation for a FRITZ!Box guest net

#! /bin/bash

if ! [[ -x "$(which edbrowse)" ]]; then echo "edbrowse needs to be installed!"; exit 2; fi

# Direct execution. Logs to the console too.
[[ "$1" == "--direct" ]] && { shift; direkt=true; } || direkt=false

log() {
  $direkt && echo "$(date '+%F %T') $1"
  logger "captive-portal: $1"
}
#log() { echo "$@"; }

captivePortal() {
  declare router=''
  warte=120
  while [[ "$warte" -gt 0 ]] && ! ip route show default | grep -qE 'default via [^ ]+ dev '"${IFACE/\./\\.}"; do
    [[ "$(( warte % 30 ))" -eq 0 ]] && log "Still waiting ${warte}s for DHCP…"
    sleep 1; (( warte-- ))
  done
  if [[ "$warte" -lt 1 ]]; then log "Given up!"; exit 2; fi
  router="$( ip route show default | awk '{ print $3 }' )"
  log "Entsperre Router: $router"
  #pfad="$( mktemp -d "/tmp/captive-portal.XXX" )"
  pfad="/etc/captive-portal"
  # `edbrowse` expects $HOME, but it may not be set, and we don’t want it to pollute a user dir in any case.
  [[ "$HOME" ]] && altesHome="$HOME"; export HOME="$pfad"
  #[[ -r "/etc/captive-portal/.ebrc" ]] && cp /etc/captive-portal/.ebrc "$pfad/"
  echo -e "hr-\n/Akzeptieren/\ni*\nqt" \
    | edbrowse "http://$router:8186/untrusted_guest.lua" \
    |& while read e; do log "edbrowse: $e"; done \
    && { log "Unlocked.";      [[ "$altesHome" ]] && export HOME="$altesHome" || unset HOME; exit 0; } \
    || { log "Failed!"; [[ "$altesHome" ]] && export HOME="$altesHome" || unset HOME; exit 1; }
  }

captivePortal

Make sure to run edbrowse once as root, and put the resulting ~/.ebrc into /etc/captive-portal/.ebrc to make it work.

It can be activated by putting the following in /etc/conf.d/net:

FILE /etc/conf.d/netHook for captive-portal

# Implement missing interface-/SSID-specific function calls:
postup() {
  if [[ $(type -t "postup_$IFVAR") == function ]]; then "postup_$IFVAR"; fi
  # There is no IFVAR-like variant of $SSID, so this won’t work:
  #if [[ $(type -t "postup_$SSID") == function ]]; then "postup_$SSID"; fi
  #if [[ $(type -t "postup_$IFVAR_$SSID") == function ]]; then "postup_$IFACE_SSID"; fi
}

# Hook captive-portal for wlan0: (Rename as needed)
postup_wlan0() { if [[ "$SSID" == "Some Captive Portal Hotspot" ]]; then captive-portal; fi; }
# There is no IFVAR-like variant of $SSID, so this won’t work:
#postup_wlan0_Some_Captive_Portal_Hotspot() { captive-portal; }

If somebody wants, he can turn this into a netifrc module.

— Evi1m4chine (talk) 11:41, 22 October 2024 (UTC)