Home › Forum › Support › Networking Issues

Log In Register Lost Password
Viewing 15 posts - 1 through 15 (of 28 total)
1 2
  • Author
    Posts
  • December 10, 2014 at 11:12 pm #834
    Andromedan
    Participant

    It seems me, along with a few others, have been having some problems getting the uRadMonitor working with our various network setups.

    In my case specifially, the unit couldn’t get an IP address via DHCP, running Wireshark on the network turned up an invalid request packet.

    If others could run a packet trace on their networks while the unit is attempting to get a DHCP lease, maybe we could start to narrow down where the issues are happening.

    In my case, the network equipment is a Virgin Superhub router, & a Cisco 48 port managed switch.

    Attachments:

    1. Screenshot-from-2014-12-10-231213.png

    December 11, 2014 at 11:53 am #839
    Peter
    Participant

    – look at the router, delete dhcp ip adress for uradmonitor. Than reconnect.

    – If you have a Fritzbox that make problems…

    – test at another router.

    Peter

    December 11, 2014 at 12:06 pm #841
    Andromedan
    Participant

    Peter, the uRadMonitor never gets a DHCP lease, as it seems to be sending an invalid DHCP request packet, or at least it’s sending something that my network equipment doesn’t like. (See attached image on my initial post).

    I have done some more testing with a separate SPI network module, the same as is installed in the uRadMonitor, which I can get working on my usual network hardware without issue, using standard example code to enable DHCP. This is pointing me more at a firmware bug on the monitor, rather than my network equipment or the network hardware in the uRadMonitor.

    Using another router does work. Unfortunately though, in the long term, segregating a seperate segment of my network is not a solution.

    This thread is to get other people to post packet captures from their network, so I can possibly work towards finding out where the problem lies. (IRL, I’m a network engineer) ;).

    December 11, 2014 at 12:11 pm #842
    Peter
    Participant

    I have the problems at the beginning…

    I think your router doesn’t like the local.mac address (02…. )

    December 11, 2014 at 12:24 pm #843
    Andromedan
    Participant

    It’s quite possible.
    Bear with me. I will set the MAC address on my alternative module to mirror that of the uRadMonitor, I will post my findings.

    If this is the root cause of the issues, at least it’s a simple fix in the firmware.

    December 11, 2014 at 12:34 pm #844
    Andromedan
    Participant

    Right. I’ve rerun some of my checks with my alternative setup.

    It isn’t the MAC address that my router has an issue with, it connected fine.

    There seems to be something missing from the DHCP packet, the uRadMonitor is sending a packet 319 bytes long, while my working test device is sending 324 bytes.

    Screenshots posted are from Wireshark & my router’s admin interface. My cloned MAC is clearly showing on the bottom line with addresss .250

    Attachments:

    1. Screenshot-from-2014-12-11-123103.png

    2. Screenshot-from-2014-12-11-123331.png

    December 11, 2014 at 8:08 pm #855
    vinz
    Member

    you’re right Andromedan, I can copy that.
    We have to check the DHCP Lib in the device…

    There are other things I’d like to check this for too: I don’t think it will handle “round robin DNS” correctly.

    Vinz

    P.S: nice, I saw this “suspicious” MAC too, hoped It will not make problems.
    Can we find out more? Are there MAC-ranges blacklisted, or others whitelisted or other techniques to find repdigit MACs?

    Attachments:

    1. dhcp_malformed.jpg

    December 11, 2014 at 8:30 pm #858
    Andromedan
    Participant

    So far as Radu has informed me, the MAC addresses are allocated based on serial number, but there shouldn’t be any reason why they’d be blacklisted. As far as I’m aware, anything can be used for a MAC address, as long as it’s unique on the network in question.

    As my previous test proves, installing my monitor’s MAC into my test environment works fine with my primary router, so I doubt it’s a MAC based issue.

    de 2E0GXE

    December 11, 2014 at 8:38 pm #860
    uRADMonitor
    Keymaster

    The 02…. are locally administered addresses. Nothing special about them just that they are free. To register universal administered addresses I will have to pay some money. I will do that in the future.

    Vinz, are you getting the same issues with DHCP? can you post more details?

    In my local tests, DHCP was fine, so it’s a bit hard for me to replicate this for a fix:

    Attachments:

    1. Screen-Shot-2014-11-30-at-17.21.58.png

    December 11, 2014 at 8:49 pm #865
    Andromedan
    Participant

    This is the strange thing, I get the same results on a router that works, even Wireshark detects the DHCP request as a valid one.

    I can only think that the DHCP frame is getting mangled somewhere by the network infrastructure, due to some freak bug in how the packet is constructed.

    The only difference I can see is the packet length, so there’s something missing from it somwehere. However I’m no expert on DHCP 😉

    Screen capture from a working router setup

    de 2E0GXE

    Attachments:

    1. Screenshot-from-2014-12-11-163311.png

    December 11, 2014 at 8:54 pm #867
    uRADMonitor
    Keymaster

    I think you’re right Ben. And this makes it strange: to get inconsistent behaviour depending on the network!

    I have a router that I know was causing some problems with uRADMonitor units. I’ll need to find it and run some tests before I can report back.

    The DHCP code was mainly written by me, and in the last revision I added the hostname option (in the form uRADMonitor-). Previously you would only see the MAC, the allocated IP and no hostname. I might have done something wrong so hopefully things will clarify.

    Another option is checking it against the Arduino implementation, but I find that complicated with all the Arduino libs and custom I/O code.

    December 11, 2014 at 9:14 pm #868
    vinz
    Member

    Hmm, I see the same packet length and the DHCP-request is also marked as malformed by Wireshark, but I do not have connection-issues.
    soo…

    And this makes it strange: to get inconsistent behaviour depending on the network!

    The DHCP Request is not the first packet.
    1) First there is a DHCP Discover sent by the uRAD, with no IP, just the MAC.
    2) Then the DHCP Server Offers an IP
    3) The uRAD Requests this IP with no own IP
    4) The Server ACKs this.

    So, when you see different behaviour in different networks, maybe there are differences in 2) ?
    Do you have both, working and not working with uRAD Device? Could you analyse that?

    Vinz

    December 11, 2014 at 9:26 pm #869
    vinz
    Member

    here you see the full communication after boot.

    Different length seems to be normal because of the device-name.
    device-name is the last piece, is it inserted correctly?

    P.S: @Radu did you see the transaction-ID in your screenshot, seems you have a musical talented device there. La lla laa La. (or drunk)

    Attachments:

    1. dhcp_malformed2.jpg

    December 11, 2014 at 9:37 pm #871
    Andromedan
    Participant

    Strangely, if I run the same Wireshark with that filter, I only get the Discover & the Request, I don’t get an offer or an ACK. And this is on the working setup.

    The Arduino implementation libraries do have one advantage – the code is very much means tested & supported by the community.

    December 12, 2014 at 11:45 am #872
    uRADMonitor
    Keymaster

    @vinz, first I didn’t know what you were talking about 🙂


    @ben    , I agree, but it mostly serves prototyping or DIY. The offer you’ve mentioned is sent by the router, right?

  • Author
    Posts
Log In Register Lost Password
Viewing 15 posts - 1 through 15 (of 28 total)
1 2
  • You must be logged in to reply to this topic.