When I have a custom loopback interface 1password extensions stop working
When I create a customer loopback interface using the below two commands
$ sudo networksetup -createnetworkservice Loopback lo0
$ sudo networksetup -setmanual Loopback 10.200.10.1 255.255.255.0
It causes 1password extensions, universally to fail.
I've upgraded 1password extensions on chrome and safari and 1password itself.
So far, I've uninstalled 1password and all extensions.
Restarted the computer and reinstalled everything.
If I remove the loopback interface everything starts working again, the moment I re-enable it it fails after a system restart.
Please advice!
1Password Version: 6.6.4
Extension Version: 4.6.4.90
OS Version: OS X 10.12.4
Sync Type: dropbox
Comments
-
Hey @tmeusburger,
That would be expected - the communication between all 1Password extensions and the 1Password apps running on the Desktop (Mac and Windows) use the localhost network interface to communicate. So changing this configuration like this will break the communication.
We are working to remove out dependency on the localhost interface and this is now available for Chrome on Windows however we still have some work to do to get this working on Mac. Sorry I don't have better news.
I'm curious though as to what your use case is if you don't mind me asking?
Looking forward to hearing back.
Best regards,
Matthew0 -
Thanks for the prompt reply! Sad to hear that it won't be a simple fix.
I'm also more than happy to satiate your curiosity =)
Right now in our development environment we use Docker to host a lot of micro services. Docker doesn't provide an easy way to call the localhost from within a running container without knowing the hosts external IP, a way around that is to use a loopback and have the container use that IP to reference the host machine.
If you use localhost / 127.0.0.1 etc inside a running container will resolve that to itself, but after running:
$ sudo networksetup -createnetworkservice Loopback lo0
$ sudo networksetup -setmanual Loopback 10.200.10.1 255.255.255.0I can reference the host machine at 10.200.10.1 from within the running container.
0 -
Hi @tmeusburger,
This isn't the first time we've seen Docker mentioned but it's the first time somebody has explained the why so thank you. Given we're trying to move away from using WebSockets I suspect we won't allocate time to trying to get them to work in this scenario but instead will continue to focus on moving away from WebSockets so that it simply becomes no longer an issue. The benefits to ditching WebSockets are numerous and will likely help both power users and developers like yourself as well as anybody that has ever had to fight with anti-virus software, more notable on the Windows side.
Now the following isn't based on anything more than curiosity but do you see the same thing if you use an address greater than 127.* ? It's most likely naivety on my part, I'm just wondering if we're falling afoul of some sort of natural ordering. I wouldn't be surprised if you can back saying it doesn't make any difference, it's just a thought that popped into my head.
0 -
Hey @littlebobbytables!
Networking definitely isn't my speciality and someone much more knowledgeable than me hopefully will chime in to provide a real answer but i experience no change in behavior between an A class network (0-127 for the first quad) or a B class network (128-191 for the first quad).
I actually tested this both for the 10.x IP above as well as a 172.x IP. Unfortunately both behave in the same way. It seems to be due to the fact that the above command overwrites the 127.0.0.1 mapping on the default lo0.
Default mac systems output of ifconfig is:
lo0: flags=8049<UP,LOOPBACK,RUNNING,MULTICAST> mtu 16384 options=1203<RXCSUM,TXCSUM,TXSTATUS,SW_TIMESTAMP> inet 127.0.0.1 netmask 0xff000000 inet6 ::1 prefixlen 128 inet6 fe80::1%lo0 prefixlen 64 scopeid 0x1 nd6 options=201<PERFORMNUD,DAD>
After executing the commands:
$ sudo networksetup -createnetworkservice Loopback lo0 $ sudo networksetup -setmanual Loopback 172.16.123.1 255.255.255.0
The output of ifconfig changes to:
lo0: flags=8049<UP,LOOPBACK,RUNNING,MULTICAST> mtu 16384 options=1203<RXCSUM,TXCSUM,TXSTATUS,SW_TIMESTAMP> inet 127.0.0.1 netmask 0xff000000 inet 172.16.123.1 netmask 0xffffff00 nd6 options=201<PERFORMNUD,DAD>
I believe if I knew how to structure the commands correctly it would result in only the alias (new ip) being mapped and not also remove the two inet6 lines. The issue I'm experiencing could be as a result of that.
Custom Workaround
In the end I was able to solve my issue by creating an alias using ifconfig. However ifconfig changes do not persist across restarts on the mac, so you need to create a custom script/plist in order to have the command executed on system boot.
I'm posting my solution here, in case someone else comes along who experiences the same problem issue. I want to call out that most docker users won't have this problem, only if they are needing to create a loopback from within the container back to the host machine (which you should never be doing in a production environment).
The ifconfig command I'm running to create the alias is:
sudo ifconfig lo0 alias 172.16.123.1
This command only adds the alias and doesn't mess up the lo0 default setup.
To have this run automatically on startup you can create a plist that gets loaded by launchd (the recommended way on mac to execute scripts).
Here is my plist file, saved as "com.lo0.loopback.plist".
<?xml version="1.0" encoding="UTF-8"?> <!DOCTYPE plist PUBLIC -//Apple Computer//DTD PLIST 1.0//EN http://www.apple.com/DTDs/PropertyList-1.0.dtd > <plist version="1.0"> <dict> <key>Label</key> <string>com.lo0.loopback</string> <key>ProgramArguments</key> <array> <string>/sbin/ifconfig</string> <string>lo0</string> <string>alias</string> <string>172.16.123.1</string> </array> <key>RunAtLoad</key> <true/> <key>Nice</key> <integer>10</integer> <key>KeepAlive</key> <false/> <key>AbandonProcessGroup</key> <true/> <key>StandardErrorPath</key> <string>/var/log/loopback-alias.log</string> <key>StandardOutPath</key> <string>/var/log/loopback-alias.log</string> </dict> </plist>
From here you just need to put it into the appropriate spot and with the correct permissions for it to be picked up by the system on startup.
cp com.lo0.loopback.plist /Library/LaunchDaemons/ chmod 0644 /Library/LaunchDaemons/com.lo0.loopback.plist chown root:wheel /Library/LaunchDaemons/com.lo0.loopback.plist launchctl load /Library/LaunchDaemons/com.lo0.loopback.plist
Launchd will then run the script for you. To verify it's working after rebooting your system run ifconfig and check the output to make sure lo0 looks like:
lo0: flags=8049<UP,LOOPBACK,RUNNING,MULTICAST> mtu 16384 options=1203<RXCSUM,TXCSUM,TXSTATUS,SW_TIMESTAMP> inet 127.0.0.1 netmask 0xff000000 inet6 ::1 prefixlen 128 inet6 fe80::1%lo0 prefixlen 64 scopeid 0x1 inet 172.16.123.1 netmask 0xffffff00 nd6 options=201<PERFORMNUD,DAD>
This fully resolves my issue until 1password has moved away from WebSockets.
0 -
Hey @littlebobbytables, tried to post a response but it looks like it got pulled, not sure why but would appreciate you reaching out so I can put my solution up for others.
0 -
Hi @tmeusburger,
I'll clean everything up in the morning but I've managed to tell our anti-spam to leave your post alone so it displays. No idea why it decided to intervene.
0 -
Holy mass submittal! Thanks for unblocking the post.
0 -
There we go, that's a little tidier :smile:
I have no idea what happened @tmeusburger but I think I've corrected and tamed it now. I'm definitely not a network expert at all and I'd say you're more savvy than the average person based on what you've been trying and found. The absence of the IPv6 aliases is definitely part of the issue as I can replicate the bad behaviour by deleting those aliases. This is puzzling because we don't specify IPv6 and all communication happens over IPv4. It means I'm not sure if it's something in 1Password or a quirk in how networking works in MacOS. Regardless I believe your approach of adding an alias is the best way of handling this and scouring various pages has yielded nothing better than your approach of making it persistent too. If MacOS has an official way of doing it otherwise it seems to be well hidden.
While Native Messaging will be great to have it would seem you don't need to wait for it at least and still use the loopback address with Docker :smile: :+1:
0 -
If I may add to this discussion:
@matthew_ag You were asking "I'm curious though as to what your use case is if you don't mind me asking?".
My case was to establish a computer-to-computer wireless network between Mac and iPad when none of them was connected to the Internet, but I needed to send files between the two systems. I was so glad to have found the option of a Loopback interface, which immediately solved my problem of sharing PDFs between Mac and iPad. This was until today when it took me close to an hour to find out why my 1Password extension no longer worked.
For the above case, i.e. computer-to-computer network connection using WiFi, with no computer being connected to the Internet, do you have any other solution?
0 -
@Horatio2000: Personally, I find the 1Password browser extensions infinitely less useful without an internet connection, but that's definitely an interesting scenario. It isn't something we're going to design around, but if you can use a secure Wi-Fi connection (either with a non-internet-connected router, or ad-hoc) that may work for you. There are probably others as well, but that's what immediately comes to mind. Cheers! :)
0 -
Hey @Horatio2000,
Thanks for letting us know! For sharing files between a Mac and an iPad, Apple provides a feature called AirDrop which allows you to send and receive files to and from your Apple devices.
This requires both your devices to be on the same WiFi network and doesn't require an internet connection. Hopefully it'll work for you!
Best regards,
Matthew0 -
My MacbookPro is from late 2009, so AirDrop is no option (though the hardware is still fine, after having replaced HDD with SSD).
Ad-hoc network (computer-to-computer) via WiFi did not work, either (NB: when I needed the wireless connection, there was neither Internet nor router etc.).
The only solution I found on the Internet was to activate Loopback, using the very terminal commands shown in the first message in this thread. This worked immediately - evidently at the expense of 1Password browser extensions.
Luckily, simply deleting the Loopback entry in system preferences/network revived the 1Password browser extensions.
Anyway, thank you for the swift feedback and suggestions,
Cheers,
Jan0 -
Likewise, thanks for sharing your scenario. We're here for you if you have any other questions about 1Password. :)
0