Yes and no, different ISP use different information when provisioning gpon onts, and for some ISPs you can clone the required information onto a rooted ONT, I am not sure this is true for all ISPs though.
For AON there really is nothing you would need from the ONT to begin with. it is very likely (but not guaranteed) that any other media-converter will wrk just as well as the existing one (including a SFP âopticâ that speaks the appropriate ethernet over fiber variant at one end and âsfpâ on the other end which might actually be compatible with your turris routerâs sfp cage*)
*) Not all SFP-modules and SFP-cage-carrying devices are compatible with each other, as nice as that would be.
the ISP pays not for the media-converters power
its likely they forced AVM HW(for the delivered ONT which must be used)
german law only describes that access has to be made available, but not that access can be used for all compatible devices (freedom of end devices is not very clear, since two devices always have to be used, there are restrictions) because there are no separate ONTs possible are
We have not established that they use some sort of hardware/MAC lock to enforce the use of their madia-converter so it is not clear they would need to do so. I was just summarizing my understandig of what the TKG law allows.
At this point this sounds pretty much like pure speculation. My best guess is that htp follows the law and allows the use of own routers and media converters, they might not make this in a convenient and easy to use fashion, but there are zero hard indications of them violating the law.
Why donât you just try it out?
And start with your own router just using their media converter before going the SFP route so you donât start with two tricky problems at the same time.
on non-fritz-boxes the ONT does not respond at all
no beginning possible
A media converter typically does not ânot-respondâ it converts between the two media and that is that. How did you diagnose âdoes not respondâ and which steps did you take.
Possible, but unlikely. It is not that others have not actually managed to use their own routers on htp glasfaser links, see e.g.:
Sure that is no guarantee that the same approach will work on your link, but at least evidence that htp does not generally violate the TKG.
no it has nothing to do with IPv4/IPv6
I checked that in detail
but i had the same respond from htp how the user in the ComputerBase forum entry
I did not claim that, I gave that as an example of an end-user that used their own non-FritzBox non-htp-supplied router on a htp fiber link, which demonstrates that is is not categorical impossible.
Not sure what that means.
However the first thing you should do if you want help is to post the information you goy from htp (just replace your actual user name with the string USERNAME and your actual password with the string PASSWORD), then show how you configured your omnia (also redact passwords) e.g. by posting the content of /etc/config/network. Then we can take it from there.
There is no guarantee that this will result in a working internet access*, but at the very least it will document the steps you took in a way that can actually be reasoned about and where folks in the know might be able to comment upon. I would guess that for your second step âreplace media-converter by SFP moduleâ documenting what you tried in a systematic fashion is also going to help.
*) HTP apparently rents some of the links from Deutsche Glasfaser and with DG end-users need to have their link changed somehow in their system to allow âeigene Routerâ so it is possible that without help from your ISP this might not work at all; only one way to find out thoughâŠ
from the ComputerBase forum entry you mentioned:
Leider kann keine Verbindung ausgebaut werden. Der Support kann nur auf Fritz Boxen verweisenâŠ
Same with me with.
i tried different routers
This is not what I asked for. I see two ways forward:
A) continue with vague description of what you tried and what the results were
B) continue with posting explicit changes and log-messages
If you pick A), please count me out that would be a waste of my time; if you pick B) I will try to continue to help you, but there is no guarantee of success (I am not a htp customer so have no first-hand experience and can not test anything myself). Your choiceâŠ
i will continue with B), but it may take me a little time.
1 Like
The same user later wrote:
Die Sache hat sich mittlerweile geklÀrt:
Der Router muss Dual Stack unterstĂŒtzen. Dann klappt auch die Einwahl.Danke fĂŒr die Antworten!
which to me indicates that he/she was successful in getting their non-FritzBox router to work.
Excellent, take your time.
The first step should be something like:
- connect the media-converters RJ45 ethernet plug with your routerâs WAN ethernet port
- confirm that there is ethernet link:
a) find your wan device using the following command on your routerâs command line (please post the output here):
ifstatus wan | grep -e device
letâs say for this discussion the result would be eth2 (replace this with your true wan device)
b) install ethtool:opkg update ; opkg install ethtool
c) look at what the wan device reports:ethtool eth2#(please post the output here)
The first thing is to confirm that you have a functioning ethernet link, then we can move on.
hmpf, it gets never an ip when a device its connected to the fiber box
Turris Box connected: no ip; my laptop connected: no ip
FritzBox7530 or FritzBox7590 connected: strangely enough: immediately an IP
ethtool reports only no ip
idk why, the rest of my network works
letâs do this step by step.
Please post the output of:
ifstatus wan | grep -e device
this might be empty, but letâs start there.
The goal is to first check that there is an ethernet link over which IP assignment might actually happen. I understand that you might consider this to be busy work, but for me to even have a chance helping you I need to get an understanding of the current status.
Also, what kind of turris MOX do you have and which port are trying?
According to MOX - Turris Documentation we need to figure out which port is exppected to be used as WAN. If I understand the link correctly if you have the mox sfp element/module none of the ethernet ports are configured for WAN usage, so do you have a mox with sfp cgae?
i use the wan port for that(eth0)
so looks it when the LAN cable is connected from fiber link box:
root@turris:~# ifconfig eth0
eth0 Link encap:Ethernet HWaddr D8:58:D7:00:BE:34
UP BROADCAST MULTICAST MTU:1500 Metric:1
RX packets:5510 errors:0 dropped:0 overruns:0 frame:0
TX packets:3581 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:532
RX bytes:5707015 (5.4 MiB) TX bytes:756931 (739.1 KiB)
Interrupt:10
and so it looks when i connect the LAN cable on another Router in my network:
root@turris:~# ifconfig eth0
eth0 Link encap:Ethernet HWaddr D8:58:D7:00:BE:34
inet addr:192.168.179.37 Bcast:192.168.179.255 Mask:255.255.255.0
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:5699 errors:0 dropped:0 overruns:0 frame:0
TX packets:3695 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:532
RX bytes:5893834 (5.6 MiB) TX bytes:772479 (754.3 KiB)
Interrupt:10
and so looks the eth1 interface(connected with my laptop)
root@turris:~# ifconfig eth1
eth1 Link encap:Ethernet HWaddr D8:58:D7:00:BE:35
inet6 addr: fe80::da58:d7ff:fe00:be35/64 Scope:Link
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:12676 errors:0 dropped:0 overruns:0 frame:0
TX packets:13016 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:532
RX bytes:2860760 (2.7 MiB) TX bytes:7870288 (7.5 MiB)
Interrupt:11
eth0 is WAN port on main module and eth1 the first LAN port on the Lan Module
but why on eth0 is not the ipv4 shown?
hmpf no ipv4 given?
in my other network all works
yes, i have additional an module with sfp cage but i can exclude the part(turris mox is a modular router). i have Mox A, G, F, E and D. module G is for mPCI connection, module F for usb3 ports, module E for 8xLAN, and module D for sfp port
This is not what I asked you forâŠbut I assume that the UP in
eth0 Link encap:Ethernet HWaddr D8:58:D7:00:BE:34
UP BROADCAST MULTICAST MTU:1500 Metric:1
indicates that ethernet ,ink is not the problemâŠ
Apparently, but that is clearly the second issue, could you share the output of:
cat /etc/config/network
please and redact all usernames and passwords.
Good so Module D is not connected then we do not need to worry too much about that.
here my network/config/network
# cat /etc/config/network
config interface 'loopback'
option ifname 'lo'
option proto 'static'
option ipaddr '127.0.0.1'
option netmask '255.0.0.0'
config globals 'globals'
option ula_prefix 'ff00:0000:ffff::/48'
config interface 'wan'
option proto 'dhcp'
option ipv6 '0'
option ifname 'eth0'
config interface 'lan'
option type 'bridge'
option macaddr '00:00:00:00:00:00'
option proto 'static'
option ipaddr '192.168.1.1'
option netmask '255.255.255.0'
option _turris_mode 'managed'
option ip6assign '60'
option bridge_empty '1'
list ifname 'lan1'
list ifname 'lan2'
list ifname 'lan3'
list ifname 'lan4'
list ifname 'lan5'
list ifname 'lan6'
list ifname 'lan7'
list ifname 'lan8'
config interface 'guest_turris'
option enabled '1'
option type 'bridge'
option proto 'static'
option ipaddr '1.1.2.1'
option netmask '255.255.255.0'
option bridge_empty '1'
config interface 'wan6'
option ifname '@wan'
option proto 'none'
wan6 should be the non used
1 Like