Looking into the Corinex CXWC-HD200-WNeH / 2022-09-17

2022-09-17 Looking into the Corinex CXWC-HD200-WNeH
Corinex CXWC-HD200-WNeH underside
Corinex CXWC-HD200-WNeH underside
Picture by Koos van den Hout, license CC-BY-SA
I have a "Corinex Detachable Wireless-N Cable Access" Corinex CXWC-HD200-WNeH to play with. This has been used for Internet access over TV coax cable in a bungalow park where it has been replaced.

So it is some sort of cable modem. According to the source it's not managed network over cable (docsis) but more like ethernet over cable, a relative of ethernet over powerline. Searching a bit finds hempro | JPK consulting which seems to be the next generation and isn't compatible.

I also found Docsis, EOC of Moca toegepast in kleine kabeltelevisienetwerken which mentions that Corinex products are ethernet over cable according to the HomePNA (abbreviated HPNA) 3.1 standard.

The only mention of these devices are for Dutch bungalow parks or campsites, for example woon op een camping, open wifi. geen internet.

The site at corinex.nl just lists why you should stop relying on these devices and replace them with newer technologies that are supported.

It's not clear to me whether I can simply set up a network with a bit of coax and another HomePNA coax interface or whether I need some sort of headend.

Time to play with the device and see how far I can get!

First poweron

Blinking leds, no smoke. On 2.4 GHz a wireless network named WiFi appears and starts interfering with other wifi networks in the neighbourhood. Nothing on 5 GHz. The 'power' and 'WLAN' leds are green, no others are active.

Trying to connect

The network WiFi has no wireless security. But trying to connect to it with my laptop gives nothing my network-manager likes.

The device also has an ethernet port. This port gives no stable link, it keeps going up and down:
20:03:49 eth0: no link
20:03:51 eth0: no link
20:03:53 eth0: negotiated 100baseTx-FD flow-control, link ok
20:03:54 eth0: no link
20:03:55 eth0: negotiated 100baseTx-FD flow-control, link ok
20:03:56 eth0: no link
20:03:59 eth0: negotiated 100baseTx-FD flow-control, link ok
20:04:00 eth0: no link
20:04:03 eth0: negotiated 100baseTx-FD flow-control, link ok
20:04:04 eth0: no link
20:04:07 eth0: negotiated 100baseTx-FD flow-control, link ok
20:04:08 eth0: no link
The next step is to get out the universal reset tool and use the 'wifi reset' button on a powerup. This doesn't change a thing.

It's not a DHCP server, turn things around

Peering deeply at tcpdump suddenly makes it very clear this device is a DHCP client and not a DHCP server:
22:00:42.264564 00:0b:c2:11:9f:bd > ff:ff:ff:ff:ff:ff, ethertype IPv4 (0x0800), length 381: 0.0.0.0.68 > 255.255.255.255.67: BOOTP/DHCP, Request from 00:0b:c2:11:9f:bd, length 339
It turns out 00:0B:C2 is indeed Corinex Communication Corp.

This explains the problem network-manager has: in the default configuration network-manager checks a new connection for a DHCP server and gives up when that fails.

So the solution to connect to it over Wifi is to use a connection profile where I set a fixed IPv4 address and run a DHCP server myself.

Using a setup where the laptop is DHCP server over wifi made the device get an address I wanted, and in capturing traffic I noticed it defaults to 10.10.1.253. The only thing I notice is that after a reboot it switches to using the other ethernet address 00:0b:c2:11:90:23. Both are on the bottom of the device.

But still no access to the webinterface

Giving it IPv4 addresses with a DHCP server makes it accept those, one for each of the given ethernet mac addresses. The device has an http interface which just returns 401 unauthorized and doesn't accept any of the username/password combinations I try. It has a DNS resolver on port 53 but forwards the DNS requests to 8.8.8.8 and 8.8.4.4 (google DNS) immediately.

If I leave it running for a while it will do an NTP request:
23:02:13.716442 00:0b:c2:11:9f:bd > 60:57:18:0b:73:36, ethertype IPv4 (0x0800), length 90: (tos 0x0, ttl 64, id 24414, offset 0, flags [DF], proto UDP (17), length 76)
    192.168.44.44.3072 > 193.67.79.202.123: NTPv3, length 48
        Client, Leap indicator:  (0), Stratum 0 (unspecified), poll 4 (16s), precision -6
        Root Delay: 1.000000, Root dispersion: 1.000000, Reference-ID: (unspec)
          Reference Timestamp:  0.000000000
          Originator Timestamp: 0.000000000
          Receive Timestamp:    0.000000000
          Transmit Timestamp:   3155673736.161927999 (2000/01/01 01:02:16)
            Originator - Receive Timestamp:  0.000000000
            Originator - Transmit Timestamp: 3155673736.161927999 (2000/01/01 01:02:16)
193.67.79.202 is ntp0.nl.uu.net. This reminds me of the problems in the past with devices all using the same NTP server without asking the owner of the server whether this was a good idea!

Current conclusion

This device is not letting me in at the moment and I don't know whether I can make it establish a link over coax. To Be Continued!

Tags: ,

IPv6 check

Running test...
, reachable as koos+website@idefix.net. PGP encrypted e-mail preferred. PGP key 5BA9 368B E6F3 34E4 local copy PGP key 5BA9 368B E6F3 34E4 via keyservers

RSS
Meningen zijn die van mezelf, wat ik schrijf is beschermd door auteursrecht. Sommige publicaties bevatten een expliciete vermelding dat ze ongevraagd gedeeld mogen worden.
My opinions are my own, what I write is protected by copyrights. Some publications contain an explicit license statement which allows sharing without asking permission.
Other webprojects: Camp Wireless, wireless Internet access at campsites
This page generated by $Id: newsitem.cgi,v 1.62 2023/09/19 14:49:50 koos Exp $ in 0.010832 seconds.