Application and device behaviors

Recording observations about the behavior of various applications and devices.

AXIS Cameras

Testing done 7/9/2021 with two AXIS M2026-LE MkII cameras running firmware version 8.40.3.

What do we learn from this testing?

At times, the AXIS Device Manager doesn't properly detect one or more cameras connected to the network. The AXIS IP Utility so far has not failed in detecting cameras. There are alternate ways to detect and access these cameras.

Behavior on boot

AXIS IP Utility

The AXIS IP Utility uses MDNS requests to discover cameras on the network. These MDNS requests are responded to by the Bonjour service running on the camera. If the Bonjour service is disabled, no response will be given.

Multiple UDP requests with different PTR queries are sent to the multicast address 224.0.0.251. The following requests were sent from the test computer to the diagnostic network with two cameras attached.

Cameras respond to the queries by sending an MDNS response to the 224.0.0.251 multicast address. The following are the responses from the two cameras connected to the diagnostic test network:

You can see that both camera responses shown above list all of the IP addresses instantiated on the camera.

AXIS Device Manager (ADM)

The AXIS Device Manager uses MDNS requests and SSDP requests to discover cameras on the network.

Using the ADM to configure a device makes more changes than just assigning the IP address. I believe multiple services are disabled, but this is still to be tested.

- more content to come

Alternate detection methods

Windows ARP Cache

Running "arp -a" on a Windows computer will display the arp cache. The link-local IP addresses instantiated by the ZeroConf service of recently booted cameras should be visible in the ARP list.

Packet sniffing using Wireshark

Wireshark can be used to observe broadcast/multicast traffic generated by cameras (especially prevalent during the initial boot) as well as ongoing DHCP requests if the camera is connected to a network lacking a DHCP server.

:end

Sharing a DYMO LabelWriter 450 Twin Turbo using CUPS and SAMBA

I wanted to if I could use a Raspberry Pi Zero W 1.1 to be a wireless USB print server for my DYMO LabelWriter 450 Twin Turbo. Here's what I learned and how to make it work. These steps should be the same regardless of server or operating system (Debian, Raspbian, Ubuntu, etc.).

Raspberry Pi

Install software
sudo apt install cups samba printer-driver-dymo

# add a user on the pi to the lpadmin group
# this is what you'll use to login to the cups web interface for adding the printer
sudo usermod -a -G lpadmin pi

sudo cupsctl --remote-any
sudo systemctl restart cups
Configure Samba

Edit /etc/samba/smb.conf and make sure the printers and print$ sections match what is shown below. You can make the print$ section writable if you need to be able to remotely manage print drivers.

[printers]
   comment = All Printers
   browseable = no
   path = /var/spool/samba
   printable = yes
   guest ok = yes
   read only = yes
   create mask = 0700

# Windows clients look for this share name as a source of downloadable printer drivers
[print$]
   comment = Printer Drivers
   path = /var/lib/samba/printers
   browseable = yes
   read only = yes
   guest ok = yes
Add the printer to CUPS
  1. Login to the CUPS service using the URL https://[ip_address]:631/admin
  2. Click Add Printer
  3. Do what is needed to add the printer.

Adding the printer to Windows

Add device - fail

I tried adding the printer using the Windows Add device option. It didn't go so well. The printer adds properly, and I can print to it from Windows, but DYMO Connect will not use the printer. Windows creates a WSD-[UUID] IPP type port and the driver maps correctly, but I never was able to get it to print successfully. It would just give an error. Doing a packet capture, I never actually saw Windows send data to the print server when trying to send a print job.

Add device - Add manually - fail then success after rename

I tried adding the printer using the Windows Add manually method by specifying the IPP URL as the printer name. It successfully adds the printer, and I can successfully send a test page job from Windows, but DYMO Connect either crashes when loading or shows the printer as disconnected. Windows appears to add a "\\" in front of the printer name. If I rename the printer using PowerShell, because I couldn't find any other way to rename it, DYMO Connect will then print successfully.

PowerShell Add-Printer Command - pure success

Below is the command used to add the printer to a Windows 11 computer that already has the DYMO Connect software installed. Everything worked perfectly.

Add-Printer -Name "DYMO LabelWriter 450 Twin Turbo on piZeroW_91" `
            -PortName "http://[ip_address]:631/printers/DYMO_LabelWriter_450_Twin_Turbo" `
            -DriverName "DYMO LabelWriter 450 Twin Turbo"

Adding the printer to OSX

After installing the DYMO Label Software, an Add Network Printer dialog is displayed. Just close it and open go to the OSX printer settings. The printer just showed up in the list and just worked. Lol

DYMO Connect Software

The DYMO Connect software will only show a printer as available if the driver used by the printer is one of their supported drivers.

InsyncHQ - InSync and InSync-Headless