IP and MAC address is funky



  • I just installed a Nest Wifi and it sees my MAC address the same as my old router which is 84:f3:eb:82:e2:4a. However when I run the command m540 I get the result of a5:a5:a5:a5:a5:a5.
    In addition, when I go into the Google Wifi app, it says IP addess unavailable but can still do a network test with it, I'm assuming via its MAC address. When I go to the IP address I have been using, I can access the Duet from a web browser. However, since the router isn't showing the IP address, I can't do port forwarding. This is something I need so that I can pause or stop a print remotely if I see an issue while I am away from home.
    My old router was having a similar port forwarding issue and I thought it was the router. Now I think it is the Duet board.
    Please help.



  • @ericlmccormick said in IP and MAC address is funky:

    I can access the Duet from a web browser

    run arp -a from windows command line an see what it thinks the mac address is? should be cached for 2-5 minutes after you access the duet with the browser.

    Hmm, dawned on me the MAC address is sort of irrelevant, but while I haven't worked with google wifi products there are a few pieces to the puzzle I'd like to know. (including the output from arp above).

    Is the Duet2Wifi (presumaly?) using a static IP or DHCP?
    Did you have to change the config / SSID when you installed the Nest Wifi?
    Does setting the MAC address manually help? Add M540 P84:F3:EB:82:E2:4A to config.g then reboot the Duet

    @ericlmccormick said in IP and MAC address is funky:

    This is something I need so that I can pause or stop a print remotely if I see an issue while I am away from home.

    I hope by this you mean you have another network with a server running a proxy for the Duet adding HTTPS and access control to things and not exposing Duet Web Control directly to the internet. Bad mojo.


  • administrators

    I confirm that on a Duet WiFi running RRF 3.01beta2, M540 reports the MAC address as all 'a5'. It looks like fetching the MAC address from the WiFi module via M540 was never implemented. The M122 report gives the correct MAC address.



  • @dc42
    I am running 2.04RC4 (2019-10-19b1)
    Running command M122 gives the following

    === Diagnostics ===
    RepRapFirmware for Duet 2 WiFi/Ethernet version 2.04RC4 running on Duet WiFi 1.02 or later
    Board ID: 08DGM-9T6BU-FG3SN-6JKD8-3SN6R-9VWMG
    Used output buffers: 3 of 24 (10 max)
    === RTOS ===
    Static ram: 25700
    Dynamic ram: 92816 of which 0 recycled
    Exception stack ram used: 268
    Never used ram: 12288
    Tasks: NETWORK(ready,764) HEAT(blocked,1176) MAIN(running,3824) IDLE(ready,160)
    Owned mutexes:
    === Platform ===
    Last reset 00:08:59 ago, cause: software
    Last software reset time unknown, reason: User, spinning module GCodes, available RAM 12332 bytes (slot 0)
    Software reset code 0x0003 HFSR 0x00000000 CFSR 0x00000000 ICSR 0x0441f000 BFAR 0xe000ed38 SP 0xffffffff Task 0x4e49414d
    Error status: 0
    Free file entries: 10
    SD card 0 detected, interface speed: 20.0MBytes/sec
    SD card longest block write time: 0.0ms, max retries 0
    MCU temperature: min 28.1, current 28.7, max 29.0
    Supply voltage: min 25.2, current 25.3, max 25.4, under voltage events: 0, over voltage events: 0, power good: yes
    Driver 0: standstill, SG min/max not available
    Driver 1: standstill, SG min/max not available
    Driver 2: standstill, SG min/max not available
    Driver 3: standstill, SG min/max not available
    Driver 4: standstill, SG min/max not available
    Date/time: 2020-01-26 14:37:36
    Cache data hit count 2090006692
    Slowest loop: 2.56ms; fastest: 0.06ms
    I2C nak errors 0, send timeouts 0, receive timeouts 0, finishTimeouts 0, resets 0
    === Move ===
    Hiccups: 0, FreeDm: 160, MinFreeDm: 160, MaxWait: 0ms
    Bed compensation in use: none, comp offset 0.000
    === DDARing ===
    Scheduled moves: 0, completed moves: 0, StepErrors: 0, LaErrors: 0, Underruns: 0, 0
    === Heat ===
    Bed heaters = 0 -1 -1 -1, chamberHeaters = -1 -1
    Heater 1 is on, I-accum = 0.0
    === GCodes ===
    Segments left: 0
    Stack records: 2 allocated, 0 in use
    Movement lock held by null
    http is idle in state(s) 0
    telnet is idle in state(s) 0
    file is idle in state(s) 0
    serial is idle in state(s) 0
    aux is idle in state(s) 0
    daemon is idle in state(s) 0
    queue is idle in state(s) 0
    autopause is idle in state(s) 0
    Code queue is empty.
    === Network ===
    Slowest loop: 35.41ms; fastest: 0.00ms
    Responder states: HTTP(0) HTTP(0) HTTP(0) HTTP(0) FTP(0) Telnet(0) Telnet(0)
    HTTP sessions: 1 of 8

    • WiFi -
      Network state is running
      WiFi module is connected to access point
      Failed messages: pending 0, notready 0, noresp 0
      WiFi firmware version 1.21
      WiFi MAC address 84:f3:eb:82:e2:4a
      WiFi Vcc 3.42, reset reason Turned on by main processor
      WiFi flash size 4194304, free heap 15672
      WiFi IP address 192.168.0.104
      WiFi signal strength -57dBm, reconnections 0, sleep mode modem
      Socket states: 0 0 0 0 0 0 0 0


  • @ericlmccormick at least the Duet knows its own MAC address after all, but it doesn't solve your problem unfortunately.

    Does creating a reservation for the MAC and IP combination help?
    https://support.google.com/googlenest/answer/6274660?hl=en



  • @bearer I can set a IP reservation but it doesn't do anything



  • I have updated the firmware in the release order to get it up to version: 3.01-beta2 (2020-01-23b1)
    The issue persist



  • @ericlmccormick said in IP and MAC address is funky:

    The issue persist

    M540 issue is only confusing, but not an actual problem. If its set up to use DHCP, and it gets an address, you can access it on your network but doesn't show up in your router then the problem is most likely elsewhere.

    Would need some sort of wireshark log to say more, but that might prove tricky if on windows.


  • administrators

    The M540 reporting issue on the Duet WiFi will be fixed in the next 3.01 beta. I have also added the MAC address to the object model.


Log in to reply