Question

Hello,

I have a weird network bug that does not manifest with 00.07.03.4 but does happen with 00.07.04.2.

Here attached you'll find the device config named "OK" with 00.07.03.4, then "KO" which is just a firmware upgrade of the same config to 00.07.04.2.

Basically the router has a SIM card that provides internet to devices plugged to the LAN port. When I plug my laptop I can surf internet just fine with both configs.

The bug happens with an AXIS cameras plugged to the router, in both cases it also resolves internet just fine (I can resolve HTTP requests when SSH'ing to the camera).

Where it differs is that the camera is unable to create an O3C tunnel.

In axis-log.txt you can see the following:

• At 15:06:35 with firmware 07.03.4 it gets internet after a router reboot and immediatly Axis O3C works ("Command channel successfully established to o3c.arqivis.com:8080").
• At 15:16:27 with firmware 07.04.2 it gets internet after firmware upgrade but Axis O3C never manages to connect. It looks like it initiates the connection properly but something is filtered when the packets are coming back and we get a timeout after 20 seconds.

Here is documentation about Axis O3C: https://cdn.axis.com/o3c_files/o3c-server-technical-reference-2.33.0-rev1.pdf

Kind regards,
Philippe

Answer 1

Hello,

  

In this case it would be interesting to see what kind of communication happens between the camera and the service.

I will ask you to navigate to Services → Package Manager → Packages and install a TCPdump package. 

Then, navigate to System → Administration → Troubleshoot. Enable the TCP dump option, select the interface as br-lan, and leave everything else on default settings. Press Save & Apply. Boot up the camera, and wait for it to not be able to connect. Then, after around 20 seconds, in the same troubleshoot menu press the Download button for the TCP dump file.

This file can be attached to the original post. I will also ask you to download a troubleshoot file from the same menu and attach it to the question as well, as backup files do not contain some necessary information.

I'll be awaiting the information!

  

Best regards,
DaumantasG

Comments

Hello,

While this is more of a question for RnD, I believe that the way MTU is being set has changed, and the mechanism requires some more optimization. It has been improved and will be released with the v7.5 update.

For now, I'd recommend leaving the MTU on 1450.

Best regards,
DaumantasG

---

@DaumantasG: how does one ask this question to RnD? I'm a developer so I'm curious and would like to be informed about what bug was found about this and be notified when a newer firmware fixes it.

---

This is probably a fragmentaion / defragmentaion issue either at the kernel or openssl level, or in the network. This sort of issue is frenquent when using wireguard telnet / http to a remote server works but ssh / https fail during establishment. The solution is to decrease the MTU of the wg interface even below the recommended wan-mtu - 80.

Just my two cents.

---

@PhilippeVaucher The exact issue and the solution will be provided in the change log once the new firmware is released (around the beginning of July). Direct contact with the RnD team is not possible, unfortunately. But as mentioned in my previous message, it is caused by incorrectly determined MTU on the mobile connection side.

    

Best regards,
DaumantasG

---

Alright thanks guys, I'll wait for new firmware then.

Kind regards,
Philippe