Help with connecting router to ISP (Australia)

Just tried to configure my new Turris Omnia to my local ISP here in Western Australia but it won’t talk to their network.

Am on a Static IP, PPPoE connection with National Broadband Network, connection via Network Termination Device on Fibre to the Premise connection with Ethernet port to router.

Have tried using DHCP, Static IP and PPPoE options and none will connect.

Using default settings with Gateway set to 192.168.1.1, Network Mask 255.255.255.0 and ISP’s DNS servers, with IPv6 disabled.

I get a message back saying the the router has been successfully configured but there is no connection established bewteen the WAN port and the ISP via the nbn Network Termination Device. Any assistance/recommendations greatly appreciated.

Cheers and thanks

Hello,
I think you need let them know that you change your MAC adress or you can set on Turris your previous MAC address.

Looks like the problem may be related to a known bug: Why didn’t they advise of this when they discovered it? Wasted at least an entire day of my life trying to fix this! Not impressed.

https://www.turris.cz/doc/en/troubleshooting/erratum

Erratum – Index of known bugs
This page contains list of known bugs.

Inability to set up PPPoE connection

Affected devices:

Turris Omnia

Affected Turris OS versions:

Turris OS 3.2

The cause is a bug in the configuration wizard (Foris). To resolve this issue please follow these instructions to flash new version of the operating system to your Omnia. Alternatively you can use a different protocol than PPPoE for the initial setup – it should be possible to switch to the PPPoE after installation of updates and finishing the setup wizard.

1 Like

They did. They published an update and sent an email to every Indiegogo backer at the time:

and see the post by Bedrich Kosata on 3 months ago:

Unfortunately, with the first feedback there are also a few issues that were reported back to us. Two are software related - one is in PPPoE support and one in SSH. We are preparing corresponding updates right now, but in the meantime we have released errata for both problems. The SSH problem does not occur on all devices, but can be easily fixed by a simple factory reset prior to installation, so I would recommend doing that the first thing after unpacking Omnia, just to be on the safe side. The last problem is about antenna connectors not being screwed tight enough in some cases. We have reported this issue to the manufacturing company and it should be OK in the current production but in case you run into this problem, it is best to take off the lid of the router and screw the nuts on the connectors tight while fixing the connector from inside holding it by the metal part.

where “errata for both problems” was a link to the actual errata document.

Thanks for that. Unfortunately, even after re-flashing the firmware and updating to the new version from USB, the Turris Omnia still won’t connect via PPPoE, Static IP or DHCP, yet, I can remove the WAN cable from the Turris and plug it straight into the old router and it works straight away. The Turris shows the WAN link connected, but the Turris doesn’t recognise the connection at the Network Termination Device.

Finally, after the most recent firmware update which patched the flaw in CHAP PPPoE authentication code, I entered the login credentials and everything instantly worked perfectly without issue. Shame that it took so long for this fundamental flaw to be addressed – I wasted countless hours trying every possible option, thinking it must have been something I was doing wrong and all along it was a flaw in the firmware that wouldn’t permit the modem to authenticate.

I only got around to installing it last night but thus far all’s good. No dramas at all with the nbn FttP NTD. Lightning fast --getting the full 100/40! The ac wifi on the Turris leaves my previous Apple WiFi access points for dead, and the wifi from the Turris router now covers a larger footprint around the house than three Apple access points did previously. Somehow even penetrating 400mm thick stone walls! And at least 3X the speed of the g/n routers.

Thrilled that it’s finally connecting to the WAN!

Finally got mine working on the Australian NBN too! Leaving the story here as well as at:

so anyone else struggling with an Omnia on the NNB can benefit by finding the experience.

Am rather deeply frustrated by the experience so far alas, and have an unresolved question. As in: why?

Here’s the low down I’ll share here and in the other thread and with Turris support (who have an open ticket on this with me).

Working base configuration:

NBN NTD UNI-D Port 1 → CAT6 cable → WAN port on Netcomm NF12

that provided fine and dandy internet.

Remove CAT6 cable from Netcomm NF12 and insert into WAN port of Omnia to produce:

NBN NTD UNI-D Port 1 → CAT6 cable → WAN port on Turris Omnia

No internet. WAN line not detected. WAN LED flashing in 7 second cycles of one second flash followed by 2 or 3 0.1 second flashes and 6 seconds off in endless repetition as documented here:

Two known Australian users with Turris Omnia on NBN, both helping me out, namely WayOutWest here and VoltageX from here:

and some support from Turris Omnia support staff. Alas no real progress quickly on working out what was causing this and still do not know! And would like to know! As learning is one my great passions.

What we did do, cornered like rats in a sense, with nowhere else to go, was try to replace on part of this system I could and I got a different CAT6 cable, so that I have:

NBN NTD UNI-D Port 1 → CAT6 cable 2 → WAN port on Turris Omnia

And suddenly the WAN LED on the Omnia is lit, albeit flickering, consistently. And yes, WAN is up and I’m posting this through it.

To wit, the cable was the cause.

And yet, the million dollar prize (in the figurative sense alas) goes to anyone who can explain how an ordinary sealed shop bought CAT6 cable can run a working PPPoE connection between an NBN NTD and a Netcomm NF12 but not between an NBN NTD and a Turris Omnia, but a different CAT 6 cable (also sealed shop bought albeit a different make and length) can?

Defy’s all my expectations.

My premises are:

  1. PPPoE is a rigorously defined universal standard
  2. CAT6 cables are a rigorously defined universal standard

Hence it is conceptually impossible (without one of these premises being wrong) for a given cable to work between two devices and not another two.

The evidence suggests one or both premises are broken and that the Omnia implements PPPoE differently to the Netcomm NF12, using perhaps a core that is missing from one cable but present in the other.

I would be genuinely pleased if Turris could weigh in and explain this.

For now, I’m rolling with the Omnia at last and thoroughly loving have an OpenWRT router in place.

Regards,

Bernd.

Hey Bernd,

Glad to hear you got your Turris working. I wonder if your experience is related to the wiring scheme used on the CAT cable? There are several ways a CAT cable can be wired and there are some circumstance where one protocol will work and one won’t. For example, I have a gigabit switch in my LAN in a rack under my desk… When I first installed it, I couldn’t get the switch to connect to my Turris through the gigabit port, but it would work fine through one of the standard 100Mb ports. I was at a loss as to what it might be, so looked at the wiring protocol on the cable and discovered it was a 1:1 cable where it goes basically orange/white, orange, blue/white, blue, green/white, green; brown/white, brown.

But for CAT-6 T568-B protocol for gigabit capacity, you need to use a different scheme

When I replaced the standard straight-through cable with the T568-B cable, the gigabit port worked immediately.

Check your cables and see whether this is the case.

I admit I’m bamboozled still. Mainly because I had thoughts like this, so ran my cable tester over both cables. And both are identically wired 1-1, through to 8-8 on all 8 wires. Further of course, both routers use PPPoE, same protocol to talk to the NTD and one cable works on both routers and the other only on the Netcomm not on the Omnia.

The only ostensible differences are that the working cable is longer, and that it is a round cable while the non-working one is a flat cable. Both though as noted are working fine with the Netcomm and my LAN is wired up heavily with these same flat patch cables, shop sealed. Total mystery.

It is a pleasure to be working though and I’m loving openWRT. Happily configuring my LAN and setup slowly with it now. Slick.

What is the output of “ifconfig” and “ethtool eth0” (I believe that eth0 is the WAN port, otherwise run “ethtool eth1”) on the omnia after connecting the working cable and after connecting the non-working cable?

# ifconfig
br-lan    Link encap:Ethernet  HWaddr D8:58:D7:00:62:E5  
          inet addr:192.168.0.1  Bcast:192.168.0.255  Mask:255.255.255.0
          inet6 addr: fe80::da58:d7ff:fe00:62e5/64 Scope:Link
          inet6 addr: fd55:c3f2:2a6::1/60 Scope:Global
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:2326077 errors:0 dropped:0 overruns:0 frame:0
          TX packets:3412206 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000 
          RX bytes:376866354 (359.4 MiB)  TX bytes:4347118496 (4.0 GiB)

eth0      Link encap:Ethernet  HWaddr D8:58:D7:00:62:E5  
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:1486981 errors:0 dropped:0 overruns:0 frame:0
          TX packets:2313332 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:532 
          RX bytes:325682404 (310.5 MiB)  TX bytes:2765656735 (2.5 GiB)
          Interrupt:37 

eth1      Link encap:Ethernet  HWaddr D8:58:D7:00:62:E6  
          inet6 addr: fe80::da58:d7ff:fe00:62e6/64 Scope:Link
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:3556344 errors:0 dropped:0 overruns:0 frame:0
          TX packets:2439003 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:532 
          RX bytes:4389181900 (4.0 GiB)  TX bytes:432000393 (411.9 MiB)
          Interrupt:38 

eth2      Link encap:Ethernet  HWaddr D8:58:D7:00:62:E7  
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:0 errors:0 dropped:0 overruns:0 frame:0
          TX packets:81325 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:532 
          RX bytes:0 (0.0 B)  TX bytes:8713499 (8.3 MiB)
          Interrupt:40 

lo        Link encap:Local Loopback  
          inet addr:127.0.0.1  Mask:255.0.0.0
          inet6 addr: ::1/128 Scope:Host
          UP LOOPBACK RUNNING  MTU:65536  Metric:1
          RX packets:111788 errors:0 dropped:0 overruns:0 frame:0
          TX packets:111788 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1 
          RX bytes:10578847 (10.0 MiB)  TX bytes:10578847 (10.0 MiB)

pppoe-wan Link encap:Point-to-Point Protocol  
          inet addr:61.68.219.95  P-t-P:10.20.22.139  Mask:255.255.255.255
          UP POINTOPOINT RUNNING NOARP MULTICAST  MTU:1492  Metric:1
          RX packets:3524061 errors:0 dropped:0 overruns:0 frame:0
          TX packets:2406608 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:3 
          RX bytes:4309710044 (4.0 GiB)  TX bytes:378070779 (360.5 MiB)

wlan0     Link encap:Ethernet  HWaddr 04:F0:21:1C:BC:07  
          inet6 addr: fe80::6f0:21ff:fe1c:bc07/64 Scope:Link
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:55285 errors:0 dropped:0 overruns:0 frame:0
          TX packets:149345 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000 
          RX bytes:5015502 (4.7 MiB)  TX bytes:111202533 (106.0 MiB)

wlan1     Link encap:Ethernet  HWaddr 04:F0:21:23:15:70  
          inet6 addr: fe80::6f0:21ff:fe23:1570/64 Scope:Link
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:810735 errors:0 dropped:0 overruns:0 frame:0
          TX packets:1121942 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000 
          RX bytes:80230670 (76.5 MiB)  TX bytes:1520618935 (1.4 GiB)

Not sure which is the WAN port. pppoe-wan is listed, and clearly the candidate but has the hallmarks of being a logical interface of sorts riding the back of a physical one (for lack of better terminology available to such a newb).

In any case:

# ethtool pppoe-wan
Settings for pppoe-wan:
No data available

so no go there. buteth1 above looks different to eth0 and eth2 in that it has a Inet6 addr, so is a prime candidate though the clues are rather indirect:

# ethtool eth1
Settings for eth1:
	Supported ports: [ TP MII ]
	Supported link modes:   10baseT/Half 10baseT/Full 
	                        100baseT/Half 100baseT/Full 
	                        1000baseT/Half 1000baseT/Full 
	Supported pause frame use: No
	Supports auto-negotiation: Yes
	Advertised link modes:  10baseT/Half 10baseT/Full 
	                        100baseT/Half 100baseT/Full 
	                        1000baseT/Half 1000baseT/Full 
	Advertised pause frame use: No
	Advertised auto-negotiation: Yes
	Link partner advertised link modes:  10baseT/Half 10baseT/Full 
	                                     100baseT/Half 100baseT/Full 
	                                     1000baseT/Half 1000baseT/Full 
	Link partner advertised pause frame use: Symmetric
	Link partner advertised auto-negotiation: Yes
	Speed: 1000Mb/s
	Duplex: Full
	Port: MII
	PHYAD: 1
	Transceiver: external
	Auto-negotiation: on
	Link detected: yes

And on LuCI I can see in fact that yes eth1 is the WAN interface:

I can try this again with the other cable but not now, perhaps on the morrow. I would be curious what ethtool eth1 reports on that other cable.

Yes, eth1 is the wan port I was looking for. I take it this is from the working configuration with the second cable? I would look for negotiation issues (speed, duplexicity, auto-negotiation) with the other cable.

Yes it’s the working cable. Trying out the other cable takes me off-line and alas it can’t reach any more from where I mounted the router and the NTD ;-). I might give it a shot tomorrow as I’m curious what ethtool would have told me.