Fixed IP Address for VintageNetDirect

mcarlin

I’m trying to set a fixed IP address for the USB VintageNetDirect type using VintageNet. Currently am trying to use the same syntax as a wired Ethernet (VintageNetEthernet), but this is failing. Below is a fragment from the target.exs.

config :vintage_net,
  regulatory_domain: "US",
  config: [
    {"usb0", 
     %{
       type: VintageNetDirect,
       ipv4: %{
        method: :static,
        address: "192.168.20.10",
        prefix_length: 24,
        gateway: "192.168.20.1",
        name_servers: ["8.8.4.4"]
       } 
      }
    },
    {"eth0",
     %{
       type: VintageNetEthernet,
       ipv4: %{method: :dhcp}
     }
    }
  ]

RingLogger shows that the configuration is failing, and usb0 is getting the internal default configuration inet 172.31.133.37 netmask 255.255.255.252. Does VintageNetDirect support fixed IP addresses?

5 comments

/nerves #vintage_net

0 1407 5

2020-07-31 19:03:56 UTC

Showing Posts 1 to 5

Show Best Posts
Show All (oldest first)
Show All (newest first)

fhunleth

Co-author of Nerves

VintageNetDirect is specialized to the point-to-point use case with no routing or anything else. If you switch your "usb0" configuration to VintageNetEthernet, it looks like the configuration should work:

config :vintage_net,
  config: [
    {"usb0", 
     %{
       type: VintageNetEthernet,
       ipv4: %{
        method: :static,
        address: "192.168.20.10",
        prefix_length: 24,
        gateway: "192.168.20.1",
        name_servers: ["8.8.4.4"]
       } 
      }
    }
  ]

Post #1

mcarlin

Thanks Frank,

This doesn’t work at compile time, but does work at runtime when I configure from the iex prompt. The IP address takes (I can ping and load web pages), but something is not as VintageNet.info returns errors after the VintageNetEthernet assignment. No big issue, I’m using this for testing multiple prototype units on the same network, we won’t be using usb networking in our production hardware. Below is a console grab if you are interested:

iex(2)> ifconfig
lo: flags=[:up, :loopback, :running]
inet 127.0.0.1 netmask 255.0.0.0
inet ::1 netmask ffff:ffff:ffff:ffff:ffff:ffff:ffff:ffff
hwaddr 00:00:00:00:00:00

sit0: flags=[]
hwaddr 00:00:00:00

usb0: flags=[:up, :broadcast, :running, :multicast]
inet 172.31.133.37 netmask 255.255.255.252 broadcast 172.31.133.37
hwaddr ca:08:56:00:13:be

iex(3)> VintageNet.configure("usb0", %{ type: VintageNetEthernet, ipv4: %{ method: :static, address: "192.168.20.10", prefix_length: 24, gateway: "192.168.20.1", name_servers: ["8.8.4.4"] } })
:ok
iex(4)> [ 73.596366] dwc2 49000000.usb-otg: dwc2_hsotg_ep_sethalt(ep 46007d83 ep1in, 0)
[ 73.603222] dwc2 49000000.usb-otg: dwc2_hsotg_ep_sethalt(ep 8db1c0f3 ep1out, 0)
[ 73.610577] dwc2 49000000.usb-otg: dwc2_hsotg_ep_sethalt(ep b82c4a2e ep2in, 0)

nil
iex(5)> ifconfig
lo: flags=[:up, :loopback, :running]
inet 127.0.0.1 netmask 255.0.0.0
inet ::1 netmask ffff:ffff:ffff:ffff:ffff:ffff:ffff:ffff
hwaddr 00:00:00:00:00:00

sit0: flags=[]
hwaddr 00:00:00:00

usb0: flags=[:up, :broadcast, :running, :multicast]
inet 192.168.20.10 netmask 255.255.255.0 broadcast 192.168.20.10
hwaddr ca:08:56:00:13:be

iex(6)> VintageNet.info
VintageNet 0.7.6

** (ArgumentError) argument error
(stdlib 3.13) :ets.match(VintageNet, {["interface" | :"$1"], :"$2"})
(vintage_net 0.7.6) lib/vintage_net/property_table/table.ex:28: VintageNet.PropertyTable.Table.get_by_prefix/2
(vintage_net 0.7.6) lib/vintage_net.ex:83: VintageNet.all_interfaces/0
(vintage_net 0.7.6) lib/vintage_net/info.ex:22: VintageNet.Info.do_info/1

-Mark

Post #2

fhunleth

Co-author of Nerves

Hi Mark,

This isn’t a configuring that I use, but I definitely want it to work as well - especially since it seems like it should.

We’ve made a few updates to VintageNet since 0.7.6. Is it possible for you to update? 0.7.9 should be a straightforward update. The latest is 0.9.0 which has breaking API changes, but they don’t affect many people. The updates include a few improvements to VintageNet.info to give more debugging information.

I don’t believe that any of the updates address whatever is causing compile-time configuration to not work. (I’m assuming that you don’t have a run-time configuration that is overriding it). In any case, could you file a bug with a few details on your device’s network connection so that we can track and fix this issue.

Thanks!!

Post #3