G120/G400 UDP not working ? Again

Is UDP working in last firmware for g120 and g400 ? I’ve an exception on both board on Bind() call:

// ep is consistent with valid address/port. (port 123)
        public static DateTime GetNetworkTime(IPEndPoint ep)
            Socket s = new Socket(AddressFamily.InterNetwork, SocketType.Dgram, ProtocolType.Udp);
            s.Bind(ep);  <======= Excepion here. (Socket Error 10022)
            byte[] ntpData = new byte[48];
            ntpData[0] = 27;
            for (int i = 1; i < 48; i++)
                ntpData[i] = 0;
            s.SendTo(ntpData, ep);

            EndPoint remoteEndPoint = ep;

            s.ReceiveFrom(ntpData, ref remoteEndPoint);
            byte offsetTransmitTime = 40;
            long intpart = (long)0;
            long fractpart = (long)0;
            for (int i = 0; i <= 3; i++)
                intpart = (long)256 * intpart + (long)ntpData[offsetTransmitTime + i];
            for (int i = 4; i <= 7; i++)
                fractpart = (long)256 * fractpart + (long)ntpData[offsetTransmitTime + i];
            long milliseconds = intpart * (long)1000 + fractpart * (long)1000 / 4294967296L;
            TimeSpan timeSpan = TimeSpan.FromTicks(milliseconds * (long)10000);
            DateTime dateTime = new DateTime(1900, 1, 1);
            dateTime = dateTime + timeSpan;

            TimeSpan offsetAmount = TimeZone.CurrentTimeZone.GetUtcOffset(dateTime);

            DateTime networkDateTime = dateTime + offsetAmount;
            return networkDateTime;

This code (may be from Jasdev codeshare) was working until few month ago.

It seems that Bind() with UDP is not allowed. Getting rid of that it works.

You need to do a bind on a receiving UDP socket in order to define the receive port. It has to be supported.

You have not shown shown the code for defining the passed EP or initializing the stack.

The ep is correctly formed pointing to a valid NTP address on port 123 and the TCP/IP stack seems initialited ok. In this moment I haven’t code to publish.
But if I comment Bind() it works fine. On full .net it works with Bind(). I can’t test on other boards now. This happens on G400 and on G120.
On the other hand it’s not needed bind on UDP sendto().

@ dobova - Perhaps, MF does not support binding to a remote port. Only a local port. After you do a SendTo(), an “auto bind” is being done to the port used for sending. The remote end sends the response back to thatport, and is received by the ReceiveFrom().

Most of the time, when a bind() is done, it is to establish a “server” port, to listen for client UDP packets.

Full .NET allows you to bind() to a remote port, and then you can just do a Send() instead of a SentTo().

Must be another example of alternatives ways of doing things in full .NET that was cut in MF.

I see lot of thread in the forum about G120/G400/EMX and ethernet.

I got a serious problem if socket (UDP or TCP) try to connect to a non valid address, where all the lwip stack seem to lock down trying to connet/sendto/receivefrom. No exception thrown, no error on timeout. Other people here have pointed out this issue.

I need “ConstrainExecution” or watchdog to manage the situation ?
Is there any update coming to solve ?

The stack was completely changed in 4.2 so the was many issues that we resolved almost all of them and we are working on fixing any other remaining issues. If you experience any issues, please report them individually and we will go though them all.

@ dobova -

I think so, this post talks more about that


@ Ghi
The problems I get are summarized as follow (G120 & G400 & Hydra):

1- If an IP address is invalid (on local net or internet) when I make a TCP socket.Connect() to a serverm, the call never return forever, no exception is thrown.

2- If I destroy the TCP socket server with some mechanism I can’t resuse the addr/port of the previous socket. This doesn’t happen all the time, but very often.

3-If an IP address is invalid (same as 1) for a UDP call to a server, the sendTo() has no problem, but the receiveFrom() never returns. Also using sockect.ReceiveTimeout it doesn’t work.

4-The HttpListner (and relative underlying socket) cannot be destroyed, also using Abort(), Close() and Stop(). The addr/port of the closed listener is never reusable unless I make a reset of the board.

5-The Socket and HttpListener aren’t reliable on long term. That is: the server socket doesn’t accept any further call after few days listening. It doesn’t depend on the traffic by the way.

Not trying to say you don’t have problems, or that they’re not fixable, but I don’t think they are all actionable on their own with just this info.

Question: do they all behave differently on the same firmware version on say EMX? Or are you just comparing previous 4.1 experience to current 4.2 on G120/G400?

Define “invalid”? Do you mean when it’s not a valid IP address (breaks the RFC spec) or do you simply mean that there’s no server listening or responding? Again, is that different on 4.2 on say EMX?

Going to be hard to repro and therefore diagnose, if it only happens occasionally… perhaps it’s not destroyed for some reason, in those cases?

“invalid” means ?? The potential issue is does ReceiveTimeout work as it’s meant to.

If it’s not destroyed, it makes sense that it’s not able to be reused. I guess the issue would be the fact that the listener termination isn’t working. Example code?

It’d be great to have a test harness to show this

@ Brett -

1 - For invalid IP I mean: No machine/appliance with that IP is reachable or no service at addr/port combination. Just use Timesevice to get an example of UDP

2 - I couldn’t find any rules on that. It seems that if there are a queue of calls on the addr/port this is very sure. So abort() doesn’t work in any case. I will simplify and show code.

3 - same as 1. Just use TimeSevice Api with an invalid NTP address to get an example of UDP failure.

4 - Yes this is the problem, probably the HttpListener termination is not working correctly. If, after a reasonable amount of time (10sec) I restart again a newly created listener on the same port it goes in exception.

5 - This is diffcult to show. I have a full .net application that calls g120 cobra II at specific interval (30sec) and get response. This works fine for few days (3 to 7) than stop responding. I’ve no clue, but I’m investigating further.

@ dobova - what firmware did you use? did you receive beta test firmware this week?

@ RobvanSchelven - I use on G120 last firmware dated May 1st 2013 and on G400 last beta dated July 12, 2013.
I know that there’s some new beta from GHI, but I haven’t.

@ dobova - I recognize all issues you mentioned. Send an email to DAT (ghi) and request for a firmware update… They fixed a number of related things.

For number #1 and number #3, I suggest use threadwrapper.
for 2,4,5, I wish you can give us more details like which device (G120, EMX, G400…), which module (ENC28, wifi, Ethernet…) and for each one, we will be very happy to do a quick test if there a sample code.