Search Unity

  1. Megacity Metro Demo now available. Download now.
    Dismiss Notice
  2. Unity support for visionOS is now available. Learn more in our blog post.
    Dismiss Notice

UNET Packet bug?

Discussion in 'UNet' started by faviann, Sep 29, 2016.

  1. faviann

    faviann

    Joined:
    Sep 9, 2015
    Posts:
    8
    Bear with me the issue is a bit hard to understand.

    We've had for a couple of month an impossible to pinpoint bug which would inexplicably cause the reliable channel to stop feeding data to the client. This week we finally had a repro on game start.

    For the repro to work, it needed a specific aspects:
    1) Repro only happens if I host the game on my machine
    2) We need to spawn a specific amount of various gameobjects for it to happen. Should the combination change, bug won't be reproduced.
    3) Related to #2, but the repro needed 3 players at the same time.


    So after a lot of investigating and eventually getting to packet inspection, I realized that the client never acknowledges receiving the data.

    I've attached two client network captures to the thread, one dump when there are no bugs (we spawned an additional unit) and one dump where it a timeout happens and kicks the clients. I've filtered it to only have the data the server sends to the client.

    The big difference between both can be seen on packet 104 of the attached dump "Bugged.pcapng".
    There is IP Fragmentation happening because the UDP datagram goes over my ethernet MTU (1500). Compare it to the other capture (NotBugged.pcapng), where I spawn an additional unit on the same frame and yet there are no fragmentation (Packet 93 & 94).

    Now I can't seem to find the information but I'm guessing the reason it's failing is because UNET is supposed to handle packet fragmentation, by itself, over UDP by specifying a max fragment size (in opposition of the IP layer handling fragmentation).

    My question is: What causes the server to send, over and over, the same packet containing the same spawn messages? (If a capture from the server side would be better let me know)
    Is IP fragmentation just coincidentally an issue?

    I can also be completely wrong but I'm at a loss trying to explain the issue at the moment and would galdly welcome any help.


    NOTE: One of the main AssetID being spawned is 3db539c9faf9656b7978e1add58e9ee7. It usually starts breaking when it tries to spawn the asset with NetID 0x43 (67 in decimal)
     

    Attached Files:

    Hightlander likes this.
  2. Hightlander

    Hightlander

    Joined:
    May 30, 2013
    Posts:
    30
    I have identical problem with ReliableSequenced channel, when router between server and client has MTU (1400). Will try to find workaround...

    Upd: Setting MTU=1300 to network interface on server machine fixes problem.


    P.S. Because it was hard to find similar problems I add keywords to comment:
    UNet, Unity networking, Network objects not spawn when connection established, UDP packet lost, Client not receive spawn messages, Second client not connect to server.
     
    Last edited: Jan 23, 2017
  3. Zullar

    Zullar

    Joined:
    May 21, 2013
    Posts:
    651
    Have you bug reported? I've had good luck with Unity QA reproducing bugs.
     
  4. faviann

    faviann

    Joined:
    Sep 9, 2015
    Posts:
    8
    Unfortunately no since the repro was not guaranteed on every machine (I think it might be related to Windows 10) felt like it would've been a waste without the context. In retrospect, reporting it was probably a better idea than posting it in the forum. Had the weird idea network devs might have been more active at reading here than via bug reports which I guess are "filtered" by another team before. I felt that without a proper repro, QAs are not gonna be able to help much and would just mark it as "Could not reproduce".

    At the time, I had taken a look at the HLAPI code of UNET (repo) and it seemed to handle it's buffer properly so I figured it might be related to the LLAPI instead (which I don't think the source is available, in-engine). Next logical step was to do a packet dump (which I sure didn't want to do but beggars can't be choosers). With a working dump vs a bugging dump, I searched for the difference before the packet drop. That's when I noticed the IP fragmentation which should not happen (if I'm not mistaken)

    Bad news is that now I lost the ability to reproduce the bug at will the bug (since it seems it depends very much on the layout of the data being buffered for the network stream).

    The good news (being hopeful) is that when Unity 5.6 releases with the new Transport Layer, a lot of the bugs/limitations from the LLAPI might be fixed.

    Crossing fingers
     
    Zullar likes this.