[Christopher Hunt]

Any further advice? Thanks.

[Christopher Hunt]

I *think* it was 1.6, but I’ve no access to the device as it is remote. The device was commissioned in July last year.

[Christopher Hunt]

After a reboot, the gateway was fine again. It’d be great to understand how this may have happened. I’ve certainly not seen it before. Thanks for any info.

[Christopher Hunt]

Thanks, Jason – any chance that these builds can be made available from the Multitech repositories? I’ve not yet set myself up for building my own images, although of course, I will if that’s what it comes down to. Clearly, there’s potential interest for mDNS on the Multitech devices. Thanks.

[Christopher Hunt]

Thanks Jeff. I did dig a little further – it appears that the architecture name that OpenWRT uses is formatted differently. They use arm_arm926ej-s whereas Multitech use arm926ejste. Adding arm_arm926ej-s to /etc/opkg/arch.conf located avahi-utils but it then tripped up looking for libc:

Collected errors:
* calculate_dependencies_for: Cannot satisfy the following dependencies for avahi-utils:
* libc * libc * libc * libc * libc * librt * libc * libc *

…which doesn’t appear to be in the OpenWRT repo…

Would it be possible to ask around within your engineering group? mDNS would be super useful. Thanks for your help.

[Christopher Hunt]

Just to add, in terms of what I’ve tried so far:

1. added to /etc/opkg/mlinux-feed.conf:

src/gz openwrt-arm926ejste https://downloads.openwrt.org/releases/packages-18.06/arm_arm926ej-s/packages

2. ran opkg update and saw the above download the package info

3. ran opkg install avahi-utils

Unfortunately, step 3 yields, “opkg_prepare_url_for_install: Couldn’t find anything to satisfy ‘avahi-utils'”. This is mysterious to me… any help here appreciated as avahi-utils appears to exist in that openwrt package repo. Thanks.

• This reply was modified 5 years ago by Christopher Hunt.
• This reply was modified 5 years ago by Christopher Hunt.
• This reply was modified 5 years ago by Christopher Hunt.

[Christopher Hunt]

I realise that this is an old post, but I’d like to add that having mDNS available to mLinux would be super helpful for the lora components. In particular, the packet-forwarder in being able to locate a remote network server on my LAN. As it stands, I have to configure the network server to have a static IP address. I’d prefer not to as it means that I have to perform remote configuration on-site with my customer once the equipment has been provided to them.

Is there any chance that mDNS could be made available? I’m using varying versions of mLinux – the one I have in front of me is 4.0.1.

Thanks for any response on this topic.

[Christopher Hunt]

Yes, I did try the upgrade after a reboot.

[Christopher Hunt]

I just tried upgrading to 1.7.2 from 1.6.4 via a reliable LAN connection. No cigar. I then thought, perhaps try 1.7.0 first. No cigar. Each time the UI reported that there was some error half way through uploading the firmware.

I then had to power-cycle the Multitech Conduit to recover. This is using AEP. Any further advice? Thanks.

[Christopher Hunt]

Thanks Jason. I’ll look at upgrading the firmware. So, just to confirm, I should expect to see the tmms field populated by the packet forward along with its receive packets…?

[Christopher Hunt]

I’ve deployed our most recent Network Server that now takes advantage of tmms. However, I’m not seeing that field come in either. Can you please advise on how I may receive the GPS time with a packet forwarder receive packet?

[Christopher Hunt]

Hang on, shouldn’t I be able to use the GPS time (tmms field)? While not quite precise, it is certainly reasonable.

`
tmms | number | GPS time of pkt RX, number of milliseconds since 06.Jan.1980
`

[Christopher Hunt]

Hi Steve,

Without precise timestamps, the Multitech and other networking hardware that it is connected to is, of course, subject to clock drift. Unless NTP is available then the observation times will be incorrect.

NTP and the internet, in general, cannot be assumed to be available for us. One of our projects in flight targets some sub-antarctic islands off New Zealand. There is no internet other than the occasional, assumed-unreliable satellite connectivity. Plenty of time for clock drift.

HTH.

Cheers,
-C

[Christopher Hunt]

Hi Steve,

Thanks so much for the fast reply. Is the lack of precise time stamping a hardware limitation or software?

Kind regards,
Christopher

[Author]

Posts