Routers

[Java Jive]

Following on from a current thread in uk.telecom.broadband entitled "How
do most people manage IP addresses on their LAN?", which mentioned
DrayTek routers quite a lot, and another in which I mentioned that I'd
just managed to acquire a Virgin Data SIM with unlimited downloads for a
really good price per month ...

I now find that my DrayTek Vigor 2830n has lost its WiFi. I am familiar
with these losing knowledge of their WiFi capabilities after a soft
reboot, evidenced when they comes back up by the disappearance of the
Wireless LAN option in the LH menu, and which can be cured by
power-cycling them, and which was supposedly cured - but in fact not
completely so, it still happened, but less often - by a firmware
update. However this is not that problem, the menu option is there, but
there is no WiFi, nothing can connect to it and WiFi Analyzer on my
tablet sees nothing coming out of it at all. I've tried taking off the
cover and reseating the wireless unit in its connector, but no change,
so, unless anyone can suggest differently, I guess it's just died.

So I'm looking for a new or decent second-hand (used) router which:
* Is for the UK market and available here
* Supports A/VDSL, Data SIM (perhaps via USB), & cable WAN
* Has WiFi to n or ac standard
* Has at least three or four Gigabit LAN ports
* When in LAN DHCP mode, properly supports local DNS
* Is affordable, say ~< £150 new, half that used.

Does anyone know of such a wondrous beast?

[Chris Green]

In uk.telecom.broadband Java Jive <ja...@evij.com.invalid> wrote:
[snip tale of woe]

>
> So I'm looking for a new or decent second-hand (used) router which:
> * Is for the UK market and available here
> * Supports A/VDSL, Data SIM (perhaps via USB), & cable WAN
> * Has WiFi to n or ac standard
> * Has at least three or four Gigabit LAN ports
> * When in LAN DHCP mode, properly supports local DNS
> * Is affordable, say ~< £150 new, half that used.
>
> Does anyone know of such a wondrous beast?

The killer is the LAN/DHCP local DNS bit, finding the rest isn't too
difficult.

--
Chris Green
·

[Andy Burns]

Java Jive wrote:

> I'm looking for a new or decent second-hand (used) router which:
>     *    Is for the UK market and available here
>     *    Supports A/VDSL, Data SIM (perhaps via USB), & cable WAN
>     *    Has WiFi to n or ac standard
>     *    Has at least three or four Gigabit LAN ports
>     *    When in LAN DHCP mode, properly supports local DNS
>     *    Is affordable, say ~< £150 new, half that used.
>
> Does anyone know of such a wondrous beast?

<https://www.ebay.co.uk/itm/bt-home-hub-5-type-a/202590913765>

plus a USB dongle for 3/4G and whack openWRT on it.

[MikeS]

I use OpenWRT but not with a USB dongle. As far as I recall it is
possible but only after a complicated install of several extra packages.
You need to be sure your chosen router will have sufficient space (the
old TP-Link routers I converted certainly do not).

If you are not familiar with OpenWRT suggest you read their Wiki pages
before buying a router to convert. If nothing else the specific model
needs to be in their extensive list of firmware downloads.

[Andy Burns]

MikeS wrote:

> Andy Burns wrote:
>
>> Java Jive wrote:
>>
>>> Does anyone know of such a wondrous beast?
>>
>> <https://www.ebay.co.uk/itm/bt-home-hub-5-type-a/202590913765>
>> plus a USB dongle for 3/4G and whack openWRT on it.
>
> I use OpenWRT but not with a USB dongle. As far as I recall it is
> possible but only after a complicated install of several extra packages.

Choose a dongle you've seen someone else has working.

> You need to be sure your chosen router will have sufficient space (the
> old TP-Link routers I converted certainly do not).

HH5a has 128MB of flash and the same of RAM, quite a change from the
original WRT54G with 4MB and 16MB

> If you are not familiar with OpenWRT suggest you read their Wiki pages
> before buying a router to convert. If nothing else the specific model
> needs to be in their extensive list of firmware downloads.

And the HH5a is on the list, as far as I'm concerned it *is* the
wonderbeast of openWRT devices, all gigabit ports, internal ADSL/VDSL
modem, dual band "ac" wifi, USB port ... all for £5

Yes you need some linux knowledge, but I'm sure Charles can handle that,
you need to be able to crack open the case and solder the serial console
connection, but if your eyesight isn't up to that just buy one of the
£20 pre-hacked versions that are also plentiful on eBay.

[Java Jive]

On 09/02/2019 11:52, Andy Burns wrote:
>
> MikeS wrote:
>
>> Andy Burns wrote:
>>
>>> Java Jive wrote:
>>>
>>>> Does anyone know of such a wondrous beast?
>>>
>>> <https://www.ebay.co.uk/itm/bt-home-hub-5-type-a/202590913765>
>>> plus a USB dongle for 3/4G and whack openWRT on it.

Thanks. Got it for under a tenner inc P&P :-) Got to be worth it even
if only on an experimental basis!

>> I use OpenWRT but not with a USB dongle. As far as I recall it is
>> possible but only after a complicated install of several extra packages.
>
> Choose a dongle you've seen someone else has working.

I already have a Huawei E3372, which I'm hoping will work.

> And the HH5a is on the list, as far as I'm concerned it *is* the
> wonderbeast of openWRT devices, all gigabit ports, internal ADSL/VDSL
> modem, dual band "ac" wifi, USB port ... all for £5

Yes, got to be worth a try before lashing out on anything more expensive.

> Yes you need some linux knowledge, but I'm sure Charles can handle that,
> you need to be able to crack open the case and solder the serial console
> connection, but if your eyesight isn't up to that just buy one of the
> £20 pre-hacked versions that are also plentiful on eBay.

That's not so good - these days it's not so much eyesight as
steadiness of hand with the soldering iron. Even the Cisco LinkSys
WT320n with a standard pitch edge connector was a little fraught, but,
anyway, when it arrives, I'll see what I can do with it.

Tx.

[Andy Burns]

Java Jive wrote:

>> you need to be able to crack open the case and solder the serial
>> console connection, but if your eyesight isn't up to that just buy one
>> of the £20 pre-hacked versions that are also plentiful on eBay.
>
> That's not so good

couple of spudgers and take it slow getting the back off to avoid
snapping little bits of plastic, I've done three, I think I found a
youtube video on where to spudge when doing the first one.

-  these days it's not so much eyesight as
> steadiness of hand with the soldering iron.  Even the Cisco LinkSys
> WT320n with a standard pitch edge connector was a little fraught, but,
> anyway, when it arrives, I'll see what I can do with it.

You need a 3.3V TTL->R232 dongle, and only need to solder RX/TX/GND
points, plus one extra pin to short to GND to put it into a special boot
mode.

[Andy Burns]

Java Jive wrote:

> I already have a Huawei E3372, which I'm hoping will work

I think that's what I have, AFAIR the default firmware runs the dongle
in "router mode" where it pretends to be a virtual ethernet device, and
that does work, but I wanted to be able to see 4G signal levels etc, so
I reflashed it into "stick mode" where it's a modem and you use it in
PPP session, that makes it shall we say "a little more interesting" to
get working with openWRT and I would recommend you leave it in the
factory mode :-)

[Michael Chare]

Soldering the serial is difficult, I ended up pulling a bit of the
circuit board when the wire I attached got moved. There is a non solder
method using cooking foil and sticky tape which I will try next. I also
ended up with a HH5B when the box I bought on ebay was not precisely
described and I was not careful enough to check properly.

[Java Jive]

On 10/02/2019 22:56, Andy Burns wrote:
>
> You need a  3.3V TTL->R232 dongle, and only need to solder RX/TX/GND
> points, plus one extra pin to short to GND to put it into a special boot
> mode.

I have a Sony DKU-5 cable that I can use on the remaining Cisco LinkSys
WRT320n and my Zyxel NSA221 NASs. I also have a TUMPA.

[Andy Burns]

Java Jive wrote:

> I also have a TUMPA

That's certainly 3.3V

[Chris Bartram]

On 11/02/2019 10:12, Michael Chare wrote:

>
> Soldering the serial is difficult, I ended up pulling a bit of the
> circuit board when the wire I attached got moved.  There is a non solder
> method using cooking foil and sticky tape which I will try next. I also
> ended up with a HH5B when the box I bought on ebay was not precisely
> described and I was not careful enough to check properly.
>
>
>

A friend of mine tried soldering the serial and broke the device. He's
pretty competent, so it must be a bit tricky.

[Java Jive]

On 10/02/2019 14:20, Java Jive wrote:
>

> That's not so good  -  these days it's not so much eyesight as
> steadiness of hand with the soldering iron.  Even the Cisco LinkSys
> WT320n with a standard pitch edge connector was a little fraught, but,
> anyway, when it arrives, I'll see what I can do with it.

Well, it arrived yesterday, and I spent half the night doing the job,
but I think I can be fairly pleased with the result:
www.macfh.co.uk/Temp/20190216_071340.jpg

The solder pads are certainly very small, so, bearing in mind the
cautions of others about ripping the tracks off the PCB, I chose the
flimsiest flex I could find - which in a former life had connected the
cartridge head of a vinyl turntable to a connector underneath its base
- in the hope that if I was accidentally a little rough, the flex would
break rather than the tracks rip off the PCB. In the event, despite
some provocation, neither of these mishaps occurred. For the other end,
I cut out a bit of old veroboard (what a strange smell that stuff has)
to the same dimension as the label in the back slot, planning to slide
it into that instead of the label, but then I realised that not only was
that a little too tight a fit for comfort, but there were four
convenient mounting points inside the case immediately behind the slot,
so I mounted it on those with the smallest screws I had, having drilled
a hole in the back in the middle of the slot to allow the pins to be
accessed from the outside, and holes for the screws The pins were the
standard breadboard/veroboard type, and were arranged so that I could
use the same connector as for my Zyxel NSA221 NASs without any further
hassle. Ta-da, success! So now the pins are covered by the label card,
the only really noticeable external evidence being that it bulges
slightly in the middle where they protrude about 1mm beyond the surface
of the case, but then at my age I too am bulging in the middle, so I'm
not complaining.

One thing that wasn't clear from the instructions was how to load the
temporary u-boot, but finally I twigged that you had to load it as a
text file, select all of it, and paste it into Putty (<rt-click>). Once
I'd got that far, it was, truly, a doddle.

So now I'm connecting via ADSL and have proper local DNS, but now I have
to work out how to get the Huawei USB 4G stick to work. I was too tired
to accomplish this last night, and there didn't seem to be anything in
the flashing instructions, so any pointers would be useful.

Tx for all the advice, which was instrumental in obtaining a good
outcome first time.

[Java Jive]

On 16/02/2019 11:52, Java Jive wrote:
>
> ... but now I have

> to work out how to get the Huawei USB 4G stick to work.

Been stuck and tearing my hair out on this all day. A search for ...
openwrt with Huawei E3372
... gets plenty of hits over the first few pages, but they're all from
several years ago, and tell me to install several modules, many of which
seem now to be in the kernel, because there's no separate download for
them. For example (anonymized):

root@OpenWRT:~# opkg install usb-modeswitch kmod-mii kmod-usb-net
kmod-usb-wdm kmod-usb-net-qmi-wwan uqmi
Package usb-modeswitch (2017-12-19-f40f84c2-1) installed in root is up
to date.
Package kmod-mii (4.9.120-1) installed in root is up to date.
Package kmod-usb-net (4.9.120-1) installed in root is up to date.
Unknown package 'kmod-usb-wdm'.
Unknown package 'kmod-usb-net-qmi-wwan'.
Unknown package 'uqmi'.
Collected errors:
* opkg_install_cmd: Cannot install package kmod-usb-wdm.
* opkg_install_cmd: Cannot install package kmod-usb-net-qmi-wwan.
* opkg_install_cmd: Cannot install package uqmi.

root@OpenWRT:~# opkg install wwan
Unknown package 'wwan'.
Collected errors:
* opkg_install_cmd: Cannot install package wwan.

The two packages most consistently appearing in these lists are ...
kmod-usb-net-cdc-ether
usb-modeswitch
... which both installed successfully, but the USB modem doesn't get
found and listed in the possible interfaces or devices:

root@OpenWRT:~# ifconfig
br-lan Link encap:Ethernet HWaddr 00:11:22:33:44:55:66
inet addr:000.111.222.333 Bcast:000.111.222.333
Mask:000.111.222.333
inet6 addr: fd05:2a4d:2b0c::1/60 Scope:Global
inet6 addr: 0000:1111:2222:3333:44444/64 Scope:Link
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:10874 errors:0 dropped:0 overruns:0 frame:0
TX packets:12565 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:1079193 (1.0 MiB) TX bytes:7454274 (7.1 MiB)

eth0 Link encap:Ethernet HWaddr 00:11:22:33:44:55:66
inet6 addr: 0000:1111:2222:3333:44444/64 Scope:Link
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:10817 errors:0 dropped:0 overruns:0 frame:0
TX packets:12553 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:1348130 (1.2 MiB) TX bytes:7556306 (7.2 MiB)

eth0.1 Link encap:Ethernet HWaddr 00:11:22:33:44:55:66
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:10786 errors:0 dropped:0 overruns:0 frame:0
TX packets:12513 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:1065365 (1.0 MiB) TX bytes:7441854 (7.0 MiB)

lo Link encap:Local Loopback
inet addr:000.111.222.333 Mask:000.111.222.333
inet6 addr: ::1/128 Scope:Host
UP LOOPBACK RUNNING MTU:65536 Metric:1
RX packets:4384 errors:0 dropped:0 overruns:0 frame:0
TX packets:4384 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1
RX bytes:400844 (391.4 KiB) TX bytes:400844 (391.4 KiB)

pppoa-wan Link encap:Point-to-Point Protocol
inet addr:000.111.222.333 P-t-P:000.111.222.333
Mask:000.111.222.333
UP POINTOPOINT RUNNING NOARP MULTICAST MTU:1500 Metric:1
RX packets:5105 errors:0 dropped:0 overruns:0 frame:0
TX packets:4212 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:3
RX bytes:3829117 (3.6 MiB) TX bytes:436937 (426.6 KiB)

wlan0 Link encap:Ethernet HWaddr 00:11:22:33:44:55:66
inet6 addr: 0000:1111:2222:3333:44444/64 Scope:Link
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:79 errors:0 dropped:0 overruns:0 frame:0
TX packets:337 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:14207 (13.8 KiB) TX bytes:64295 (62.7 KiB)

wlan1 Link encap:Ethernet HWaddr 00:11:22:33:44:55:66
inet6 addr: 0000:1111:2222:3333:44444/64 Scope:Link
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:7 errors:0 dropped:0 overruns:0 frame:0
TX packets:256 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:813 (813.0 B) TX bytes:46826 (45.7 KiB)

If anyone can help me get the Huawei USB stick going I'd be most grateful.

[Andy Burns]

Java Jive wrote:

> If anyone can help me get the Huawei USB stick going I'd be most grateful.

Presumably it's got the "Hilink mode" firmware, rather than the "Stick
mode" firmware installed?

If you plug it into a Windows PC (with wifi and ethernet disabled) do
you see an additional 'ethernet over USB' interface with a router
address, I think it has a web interface on that address.

I replaced mine with stick mode, and that works fine on a Fedora PC with
ModemManager/NetworkManager, but not with openWRT as it crashes a lantiq
USB module.

You seem to have the right sort of extras installed, here's my list that
I install after every upgrade, obviously they're not all dongle related...

opkg install curl htop ip-full lm-sensors procps-ng-ps arp-scan
opkg install luci luci-app-sqm luci-proto-ncm luci-app-wol
opkg install usb-modeswitch usbutils comgt-ncm minicom
opkg install kmod-usb-net-huawei-cdc-ncm kmod-usb-serial-wwan
kmod-usb-serial-wwan kmod-usb-serial-option kmod-nf-nathelper-extra

[Java Jive]

On 17/02/2019 09:00, Chronos wrote:

> On Sat, 16 Feb 2019 22:08:05 +0000
> Java Jive <ja...@evij.com.invalid> wrote:
>
>> Unknown package 'kmod-usb-wdm'.
>> Unknown package 'kmod-usb-net-qmi-wwan'.
>> Unknown package 'uqmi'.
>

> Have you performed an opkg update? Like apt, opkg needs to know the
> file name, size and hash of the remote package before it will do
> anything with the install directive.

Yes, I have, before installing the two that worked.

> There's also a very good chance
> that whatever build you're using

openwrt-18.06.1-lantiq-xrx200-bt_homehub-v5a-squashfs-sysupgrade.bin

> doesn't have those packages compiled
> as modules (installable by opkg) and you *may* have to build your own,
> which sounds daunting but with OpenWRT's buildroot is fairly
> straightforward.

Oh yech! My experience of trying to improve my NASs this way didn't end
well!

> You'll also need mwan3

root@MacFH:~# opkg install mwan3
Installing mwan3 (2.6.18-1) to root...
Downloading
http://downloads.openwrt.org/releases/18.06.1/packages/mips_24kc/packages/mwan3_2.6.18-1_all.ipk
Installing libmnl (1.0.4-1) to root...
Downloading
http://downloads.openwrt.org/releases/18.06.1/packages/mips_24kc/base/libmnl_1.0.4-1_mips_24kc.ipk
[...]
Configuring kmod-nfnetlink.
[...]
Configuring mwan3.
RTNETLINK answers: File exists
Failed to parse message data
Failed to parse message data

> and its associated luci front-end

How would I install that?

> for failover
> duty, which pulls in iproute2 and associated advanced routing bits. You
> can do it manually with hotplugd and iproute2 (I use a wireguard VPN and
> have iproute2 directing traffic between the main WAN and the VPN using
> ip rule statements and tagging) but it's much faff on the command
> line.

Last part of that is a little beyond me, but failover might be important
- if by that is meant that if one WAN source fails another seamlessly
takes its place.

The idea is that I discontinue my landline in favour of 4G/LTE, but when
I tried the latter with my DrayTek Vigor 2830n it was very unreliable -
the moment I started to download anything significant in size it would
lose connection, and then the DV didn't seem able to pick up the
landline to replace it, and would require rebooting to get things going
again. However, now that the DV has partially died, I'm wondering if
its remaining functionality was and is also flaky, and therefore that
discontinuing my landline may still be a viable option. However, to
make that decision, obviously I need first to get the Huawei to work
reliably with the BTHH5a.

[Java Jive]

On 17/02/2019 09:25, Andy Burns wrote:
> Java Jive wrote:
>
>> If anyone can help me get the Huawei USB stick going I'd be most
>> grateful.
>
> Presumably it's got the "Hilink mode" firmware, rather than the "Stick
> mode" firmware installed?

Not entirely sure, but I don't think so. when plugged into a laptop,
there is nothing to be found at 192.168.8.1. The Mobile Partner
software version is 23.015.02.00.03, whereas that older debate seemed to
be between 21.x and 22.x.

> If you plug it into a Windows PC (with wifi and ethernet disabled) do
> you see an additional 'ethernet over USB' interface with a router
> address, I think it has a web interface on that address.

IPConfig shows (anonymized):

Ethernet adapter Local Area Connection 7:

Connection-specific DNS Suffix . :
Description . . . . . . . . . . . : HUAWEI Mobile Connect -
Network Card
Physical Address. . . . . . . . . : 00-11-22-33-44-55
Dhcp Enabled. . . . . . . . . . . : Yes
Autoconfiguration Enabled . . . . : Yes
IP Address. . . . . . . . . . . . : 10.108.52.xxx
Subnet Mask . . . . . . . . . . . : 255.255.255.224
IP Address. . . . . . . . . . . . : 0000::111:2222:3333:0%6
Default Gateway . . . . . . . . . : 10.108.52.225
DHCP Server . . . . . . . . . . . : 10.108.52.225
DNS Servers . . . . . . . . . . . : 194.168.4.100
194.168.8.100
fec0:0:0:ffff::1%1
fec0:0:0:ffff::2%1
fec0:0:0:ffff::3%1
Lease Obtained. . . . . . . . . . : 17 February 2019 13:28:44
Lease Expires . . . . . . . . . . : 23 February 2019 13:28:44

Speedtest.net gives me 85ms 24.36Mbps 0.89Mbps

> I replaced mine with stick mode, and that works fine on a Fedora PC with
> ModemManager/NetworkManager, but not with openWRT as it crashes a lantiq
> USB module.
>
> You seem to have the right sort of extras installed, here's my list that
> I install after every upgrade, obviously they're not all dongle related...
>
> opkg install curl htop ip-full lm-sensors procps-ng-ps arp-scan
> opkg install luci luci-app-sqm luci-proto-ncm luci-app-wol
> opkg install usb-modeswitch usbutils comgt-ncm minicom
> opkg install kmod-usb-net-huawei-cdc-ncm kmod-usb-serial-wwan
> kmod-usb-serial-wwan kmod-usb-serial-option kmod-nf-nathelper-extra

Ah! STOP PRESS - Some new information!

I hadn't realised that it seems to be necessary to run ...
opkg update
... before you run ...
opkg install xxx
... EVEN THOUGH you have updated recently. It seems the data it
produces is volatile and doesn't survive for long - my initial thought
was that most probably it's lost after a system reboot &/or power
cycling, but I've just disproved this. So, for example:

Yesterday, even though ...
opkg update
... had been performed earlier that day ...

root@OpenWRT:~# opkg install usb-modeswitch kmod-mii kmod-usb-net
kmod-usb-wdm kmod-usb-net-qmi-wwan uqmi

[...]

Unknown package 'kmod-usb-wdm'.
Unknown package 'kmod-usb-net-qmi-wwan'.
Unknown package 'uqmi'.
Collected errors:
* opkg_install_cmd: Cannot install package kmod-usb-wdm.
* opkg_install_cmd: Cannot install package kmod-usb-net-qmi-wwan.
* opkg_install_cmd: Cannot install package uqmi.
root@OpenWRT:~# opkg install wwan
Unknown package 'wwan'.
Collected errors:
* opkg_install_cmd: Cannot install package wwan.

Today ...

root@MOpenWRT:~# opkg update
Downloading
http://downloads.openwrt.org/releases/18.06.1/targets/lantiq/xrx200/packages/Packages.gz
Updated list of available packages in /var/opkg-lists/openwrt_core
Downloading
http://downloads.openwrt.org/releases/18.06.1/targets/lantiq/xrx200/packages/Packages.sig
Signature check passed.
[...]
root@MOpenWRT:~# opkg install usb-modeswitch kmod-mii kmod-usb-net
kmod-usb-wdm kmod-usb-net-qmi-wwan uqmi
[...]
Installing kmod-usb-wdm (4.9.120-1) to root...
Downloading
http://downloads.openwrt.org/releases/18.06.1/targets/lantiq/xrx200/packages/kmod-usb-wdm_4.9.120-1_mips_24kc.ipk
Installing kmod-usb-net-qmi-wwan (4.9.120-1) to root...
Downloading
http://downloads.openwrt.org/releases/18.06.1/targets/lantiq/xrx200/packages/kmod-usb-net-qmi-wwan_4.9.120-1_mips_24kc.ipk
Installing uqmi (2016-12-19-8ceeab69-3) to root...
Downloading
http://downloads.openwrt.org/releases/18.06.1/targets/lantiq/xrx200/packages/uqmi_2016-12-19-8ceeab69-3_mips_24kc.ipk
Installing wwan (2014-07-17-1) to root...
Downloading
http://downloads.openwrt.org/releases/18.06.1/packages/mips_24kc/base/wwan_2014-07-17-1_mips_24kc.ipk
Configuring kmod-usb-wdm.
Configuring kmod-usb-net-qmi-wwan.
Configuring wwan.
Configuring uqmi.
root@MOpenWRT:~# opkg install wwan
Package wwan (2014-07-17-1) installed in root is up to date.

... then power-cycle and log back in ...

root@MOpenWRT:~# opkg install wwan
Package wwan (2014-07-17-1) installed in root is up to date.

... so I don't know how and when the update data was lost yesterday, but
clearly somehow it was so.

And anyway I *still* can't see either anything like eth1 or wwan0 in the
list of interfaces. Grrr!

[Java Jive]

On 17/02/2019 15:39, Chronos wrote:

>
> On Sun, 17 Feb 2019 13:22:12 +0000
> Java Jive <ja...@evij.com.invalid> wrote:
>>
>> How would I install that?
>

> # opkg install luci-app-mwan3

Same again, previous update data lost:

root@MOpenWRT:~# opkg install luci-app-mwan3
Unknown package 'luci-app-mwan3'.
Collected errors:
* opkg_install_cmd: Cannot install package luci-app-mwan3.

root@MOpenWRT:~# opkg update
Downloading
http://downloads.openwrt.org/releases/18.06.1/targets/lantiq/xrx200/packages/Packages.gz
Updated list of available packages in /var/opkg-lists/openwrt_core
Downloading
http://downloads.openwrt.org/releases/18.06.1/targets/lantiq/xrx200/packages/Packages.sig
Signature check passed.
[...]

root@MOpenWRT:~# opkg install luci-app-mwan3
Installing luci-app-mwan3 (git-19.046.40869-30d9bc0-1) to root...
Downloading
http://downloads.openwrt.org/releases/18.06.1/packages/mips_24kc/luci/luci-app-mwan3_git-19.046.40869-30d9bc0-1_all.ipk
Installing libuci-lua (2018-08-11-4c8b4d6e-1) to root...
Downloading
http://downloads.openwrt.org/releases/18.06.1/packages/mips_24kc/base/libuci-lua_2018-08-11-4c8b4d6e-1_mips_24kc.ipk
Configuring libuci-lua.
Configuring luci-app-mwan3.

>> The idea is that I discontinue my landline in favour of 4G/LTE, but
>> when I tried the latter with my DrayTek Vigor 2830n it was very
>> unreliable - the moment I started to download anything significant
>> in size it would lose connection, and then the DV didn't seem able to
>> pick up the landline to replace it, and would require rebooting to
>> get things going again.
>

> I wonder if Virgin's "unlimited" actually means "terms and conditions,
> including a FUP, apply and your kneecaps may be at risk if you exceed
> mobe levels of data" which would be pretty much standard for cheap
> deals from sh^H^Hmobile networks, especially virtual ones. That could
> mean a traffic profile filter kicking in.

Well, there may be, almost certainly is, some sort of traffic control,
but the package is *Unlimited* data, so, while I'd expect some sort of
slow down at busy periods as voice gets preference, I wouldn't expect
being cut off altogether in such a way as the whole connection is f*ked.
If that turns out to be what is really happening, then I'll be calling
in the attention of both Ofcom and the ASA.

> I'm not seeing a CDC eth1 in your ip a list, just pppoa-wan which
> I'm assuming is your DSL connection,

Yes, correct.

> which looks to me like the Huawei
> is still in one of its other modes. What does manually running
> "/etc/init.d/usbmode enable && /etc/init.d/usbmode start" do?

Nothing, in the sense there is no message returned by the commands, but
I suppose at least that means there was no error, but still nothing new
in ifconfig's output, nor the GUI that I can see, but I note that at the
bottom of the status page there is a section I hadn't noticed before,
the output is in boxes across the page and read:

MWAN Interfaces

Interface: wan
Status: Online

Interface: wan6
Status: Disabled

Interface: wanb
Status: Disabled

Interface: wanb6
Status: Disabled

I am puzzled by both wan6 and wanb. According to the interfaces page,
wan6 should be up and running, but obviously it isn't, so why not? And
is wanb the missing Huawei? If so, why is it present even when the
router is rebooted without the Huawei plugged in? I presume therefore
it's just the ethernet WAN port on the back?

> If that
> brings eth1 into the list, the usb-modeswitch service wasn't enabled
> during the package install. At that point you should be able to follow
> this:
>
> https://protyposis.net/blog/using-the-huawei-e3372-hi-link-lte-dongle-with-openwrt/

Yes, I think I've seen that page before, also, among others:
https://gist.github.com/bjoern-r/1345e8a17f4acf41006330e688af1441

However, as in my reply to Andy, there's nothing at 192.168.8.1, even
when the Huawei is plugged into a PC.

[Andy Burns]

Java Jive wrote:

> Chronos wrote:
>
> whatever build you're using
>
> openwrt-18.06.1-lantiq-xrx200-bt_homehub-v5a-squashfs-sysupgrade.bin

if you're using 18.06.1 you shouldn't need to build packages or modules,
I've even found the nightlies include them

[Andy Burns]

Java Jive wrote:

> Same again, previous update data lost:
>
> root@MOpenWRT:~# opkg install luci-app-mwan3
> Unknown package 'luci-app-mwan3'.

still sounds like you haven't (successfully?) done an "opkg update"
before doing any "opkg install" commands

I'm on the same version as you and it installs the mwan3 and its
dependencies.

[Andy Burns]

Java Jive wrote:

> And anyway I *still* can't see either anything like eth1 or wwan0 in the
> list of interfaces.  Grrr!

I don't think ypu should see /dev/ttyUSB type devoces, because you're
using fake ethernet, rather than fake serial port mode, I'm using the
latter hence instaling minicom in order to send it hayes AT style
commands to "dial" but I suspect you need usbmodeswitch to put the
dongle into fake ethernet mode?

[MikeS]

On 17/02/2019 14:36, Java Jive wrote:
> On 17/02/2019 11:15, MikeS wrote:
>>
>> You will need to be sure that the router firmware is finding the modem
>> and not a USB stick/CDROM with the drivers etc.
>
> I think I'm right in saying that it's not either/or  -  as long as the
> right modules are loaded, both should be found automatically.
>
I originally bought the TP-Link routers I mentioned previously for use
with 3G dongles. Their firmware simply reported "modem identified" even
on first use, never any indication of a USB drive.

I also used the same dongles with various versions of Windows whose
behavior varied. Sometimes the device no longer appeared as a USB stick
after the modem was installed, other times it was still there even with
the modem working correctly.

[Java Jive]

On 17/02/2019 18:39, MikeS wrote:
>
> I also used the same dongles with various versions of Windows whose
> behavior varied. Sometimes the device no longer appeared as a USB stick
> after the modem was installed, other times it was still there even with
> the modem working correctly.

My experience is the latter, on both XP and W7 the storage remains
accessible even while the stick is connected.

[Java Jive]

On 16/02/2019 22:08, Java Jive wrote:
>
> Been stuck and tearing my hair out on this all day.

I'm gradually discovering more about this problem ...

1) As already posted, at least in the case of packages that haven't been
installed, the information arising from ...
opkg update
... is volatile and doesn't last, and therefore it should be considered
de riguer to run the above command before every attempt to install a new
package.

Next, some more new information. I've now discovered that the Huawei
E3372 devices come in either an 's' or an 'h' designation, which
respectively indicate serial and hilink modes. Looking back, I see
that, not being aware of the importance of the differences, I didn't
specify which mine is, and I can only apologise for that, mine is an:
Huawei E3372s

So I've been reading through ...
https://openwrt.org/docs/guide-user/network/wan/wwan/3gdongle

I've installed ...

comgt
kmod-usb-serial
kmod-usb-serial-option
kmod-usb-serial-wwan
usb-modeswitch
wwan
mwan3 luci-app-mwan3

... and I've got as far as getting two ttyUSBx devices, but not
everything mentioned in this quote:

"Check dmesg for:

USB Serial support registered for generic
usbserial_generic 1-1:1.0: generic converter detected
USB Serial support registered for generic
usbserial_generic 1-1:1.0: generic converter detected
usb 1-1: generic converter now attached to ttyUSB0
usbserial_generic 1-1:1.1: generic converter detected
usb 1-1: generic converter now attached to ttyUSB1
...
usbcore: registered new interface driver usbserial_generic
usbserial: USB Serial Driver core
USB Serial support registered for GSM modem (1-port)
usbcore: registered new interface driver option
option: v0.7.2:USB Driver for GSM modems"

I have ...

"usbcore: registered new interface driver option
usbserial: USB Serial support registered for GSM modem (1-port)
...
option 1-1:1.0: GSM modem (1-port) converter detected
usb 1-1: GSM modem (1-port) converter now attached to ttyUSB0
option 1-1:1.1: GSM modem (1-port) converter detected
usb 1-1: GSM modem (1-port) converter now attached to ttyUSB1"

... but still no modem visible in either ifconfig or the GUI.

[Andy Burns]

Java Jive wrote:

> I've now discovered that the Huawei E3372 devices come in either an 's'
> or an 'h' designation

The "Hilink" or "Stick" option I asked about, I suspect you'll likely
run into the same problem I have, that as soon as the PPP stack starts
talking to the modem device the USB driver panics the kernel ...

[Andy Burns]

I reported it here

<https://bugs.openwrt.org/index.php?do=details&task_id=1367>

someone else confirmed it happened for them, I've not checked it since
going back from nightly snapshots to 18.06.1

I looked at the source around the region of the reported panic and
couldn't see what was going on.

A forum post I made too, might help

<https://forum.openwrt.org/t/huawei-e3372-with-ncm/11778>

[Java Jive]

First, let me thank Chronos & Andy for their continuing help ...

On 18/02/2019 07:18, Chronos wrote:
>
> On Mon, 18 Feb 2019 00:27:27 +0000
> Java Jive <ja...@evij.com.invalid> wrote:
>>
>> Huawei E3372s
>
> Yes, that's extremely important. Yours is the variant which appears to
> be a serial modem, hence the "s" suffix, and accepts Hayes AT control
> commands rather than appearing as a virtual NATted NIC.

>
>> ... but still no modem visible in either ifconfig or the GUI.
>

> No, there won't be. The WANx interface won't appear until pppd is
> running and connected to the APN. You need luci-proto-3g

Successfully installed.

> to enable the
> GUI's serial dongle handling interface. At that point you should be
> able to supply it with the /dev/ttyUSB0 device, the apn, username and
> password and it should Just Work™. I know it's counter-intuitive that
> the package mentions 3G when your dongle is LTE but they both use the
> same chat script to connect.

I still couldn't see any relevant device or interface when I chose ...
Network
Interfaces
Add new interface
Cover the following interface
... and I didn't know what to enter as 'Custom interface'.

> As an aside, dmesg will tell you nothing about the pppd process. You'll
> get the USB serial devices appearing but you need logread to see what
> pppd is up to.

Noted, as below ...

Continuing on from the previously posted OpenWRT link ...

https://openwrt.org/docs/guide-user/network/wan/wwan/3gdongle#manual_configuration

... I added a 'wanb' and a 'wanb6' by manually editing ...
/etc/network/config
... and entering skeletal information, and this enabled the new
interfaces to come up under Network, Interfaces. I then edited these in
the GUI so that the two sections in the file now read as follows:

config interface 'wanb'
option proto '3g'
option service 'umts'
option apn 'goto.virginmobile.uk'
option ipv6 'auto'
option dialnumber '*99#'
option pincode '2604'
option device '/dev/ttyUSB1'

config interface 'wanb6'
option ifname '@wanb'
option proto 'dhcpv6'
option reqaddress 'try'
option reqprefix 'auto'

First I tried ...
option device '/dev/ttyUSB0'
... but it fails to connect as follows:

Mon Feb 18 13:03:03 2019 daemon.notice netifd: wanb (1659): Trying to
set PIN
Mon Feb 18 13:03:03 2019 daemon.notice netifd: wanb (1659): PIN set
successfully
Mon Feb 18 13:03:04 2019 daemon.notice netifd: wanb (1659): Trying to
set mode
[...]
Mon Feb 18 13:03:05 2019 daemon.notice pppd[2190]: pppd 2.4.7 started by
root, uid 0
[...]
Mon Feb 18 13:03:06 2019 local2.info chat[2262]: abort on (BUSY)
Mon Feb 18 13:03:06 2019 local2.info chat[2262]: abort on (NO CARRIER)
Mon Feb 18 13:03:06 2019 local2.info chat[2262]: abort on (ERROR)
Mon Feb 18 13:03:06 2019 local2.info chat[2262]: report (CONNECT)
Mon Feb 18 13:03:06 2019 local2.info chat[2262]: timeout set to 10 seconds
Mon Feb 18 13:03:06 2019 local2.info chat[2262]: send (AT&F^M)
Mon Feb 18 13:03:06 2019 local2.info chat[2262]: expect (OK)
Mon Feb 18 13:03:06 2019 local2.info chat[2262]: AT&F^M^M
Mon Feb 18 13:03:06 2019 local2.info chat[2262]: OK
Mon Feb 18 13:03:06 2019 local2.info chat[2262]: -- got it
Mon Feb 18 13:03:06 2019 local2.info chat[2262]: send (ATE1^M)
Mon Feb 18 13:03:07 2019 local2.info chat[2262]: expect (OK)
Mon Feb 18 13:03:07 2019 local2.info chat[2262]: ^M
Mon Feb 18 13:03:07 2019 local2.info chat[2262]: ATE1^M^M
Mon Feb 18 13:03:07 2019 local2.info chat[2262]: OK
Mon Feb 18 13:03:07 2019 local2.info chat[2262]: -- got it
Mon Feb 18 13:03:07 2019 local2.info chat[2262]: send
(AT+CGDCONT=1,"IP","goto.virginmobile.uk"^M)
Mon Feb 18 13:03:07 2019 local2.info chat[2262]: timeout set to 30 seconds
Mon Feb 18 13:03:07 2019 local2.info chat[2262]: expect (OK)
Mon Feb 18 13:03:07 2019 local2.info chat[2262]: ^M
Mon Feb 18 13:03:07 2019 local2.info chat[2262]:
AT+CGDCONT=1,"IP","goto.virginmobile.uk"^M^M
Mon Feb 18 13:03:07 2019 local2.info chat[2262]: OK
Mon Feb 18 13:03:07 2019 local2.info chat[2262]: -- got it
Mon Feb 18 13:03:07 2019 local2.info chat[2262]: send (ATD*99#^M)
Mon Feb 18 13:03:07 2019 local2.info chat[2262]: expect (CONNECT)
Mon Feb 18 13:03:07 2019 local2.info chat[2262]: ^M
Mon Feb 18 13:03:07 2019 local2.info chat[2262]: ATD*99#^M^M
Mon Feb 18 13:03:07 2019 local2.info chat[2262]: CONNECT
Mon Feb 18 13:03:07 2019 local2.info chat[2262]: -- got it
Mon Feb 18 13:03:07 2019 local2.info chat[2262]: send ( ^M)
Mon Feb 18 13:03:07 2019 daemon.info pppd[2190]: Serial connection
established.
Mon Feb 18 13:03:07 2019 kern.info kernel: [ 38.126483] 3g-wanb:
renamed from ppp0
Mon Feb 18 13:03:07 2019 daemon.info pppd[2190]: Using interface 3g-wanb
Mon Feb 18 13:03:07 2019 daemon.notice pppd[2190]: Connect: 3g-wanb <-->
/dev/ttyUSB0
[...]
Mon Feb 18 13:03:38 2019 daemon.warn pppd[2190]: LCP: timeout sending
Config-Requests
Mon Feb 18 13:03:38 2019 daemon.notice pppd[2190]: Connection terminated.
Mon Feb 18 13:03:39 2019 daemon.notice pppd[2190]: Modem hangup
Mon Feb 18 13:03:39 2019 daemon.info pppd[2190]: Exit.
Mon Feb 18 13:03:39 2019 daemon.notice netifd: Interface 'wanb' is now down

Next I tried ...
option device '/dev/ttyUSB1'
... but, although it connects as follows, it's treacle slow, and unreliable:

Mon Feb 18 13:06:42 2019 daemon.notice netifd: Interface 'wanb' is
setting up now
[...]
Mon Feb 18 13:06:46 2019 user.notice mwan3[1623]: Using firewall mask 0x3F00
Mon Feb 18 13:06:46 2019 user.notice mwan3[1623]: Max interface count is 60
[...]
Mon Feb 18 13:06:47 2019 daemon.notice netifd: wanb (1628): Trying to
set PIN
[...]
Mon Feb 18 13:06:48 2019 daemon.notice netifd: wanb (1628): PIN set
successfully
[...]
Mon Feb 18 13:06:49 2019 daemon.notice netifd: wanb (1628): Trying to
set mode
Mon Feb 18 13:06:50 2019 daemon.notice pppd[2142]: pppd 2.4.7 started by
root, uid 0
Mon Feb 18 13:06:51 2019 local2.info chat[2219]: abort on (BUSY)
Mon Feb 18 13:06:51 2019 local2.info chat[2219]: abort on (NO CARRIER)
Mon Feb 18 13:06:51 2019 local2.info chat[2219]: abort on (ERROR)
Mon Feb 18 13:06:51 2019 local2.info chat[2219]: report (CONNECT)
Mon Feb 18 13:06:51 2019 local2.info chat[2219]: timeout set to 10 seconds
Mon Feb 18 13:06:51 2019 local2.info chat[2219]: send (AT&F^M)
Mon Feb 18 13:06:51 2019 local2.info chat[2219]: expect (OK)
Mon Feb 18 13:06:51 2019 local2.info chat[2219]: AT&F^M^M
Mon Feb 18 13:06:51 2019 local2.info chat[2219]: OK
Mon Feb 18 13:06:51 2019 local2.info chat[2219]: -- got it
Mon Feb 18 13:06:51 2019 local2.info chat[2219]: send (ATE1^M)
Mon Feb 18 13:06:51 2019 local2.info chat[2219]: expect (OK)
Mon Feb 18 13:06:51 2019 local2.info chat[2219]: ^M
Mon Feb 18 13:06:51 2019 local2.info chat[2219]: ATE1^M^M
Mon Feb 18 13:06:51 2019 local2.info chat[2219]: OK
Mon Feb 18 13:06:51 2019 local2.info chat[2219]: -- got it
Mon Feb 18 13:06:51 2019 local2.info chat[2219]: send
(AT+CGDCONT=1,"IP","goto.virginmobile.uk"^M)
Mon Feb 18 13:06:52 2019 local2.info chat[2219]: timeout set to 30 seconds
Mon Feb 18 13:06:52 2019 local2.info chat[2219]: expect (OK)
Mon Feb 18 13:06:52 2019 local2.info chat[2219]: ^M
Mon Feb 18 13:06:52 2019 local2.info chat[2219]:
AT+CGDCONT=1,"IP","goto.virginmobile.uk"^M^M
Mon Feb 18 13:06:52 2019 local2.info chat[2219]: OK
Mon Feb 18 13:06:52 2019 local2.info chat[2219]: -- got it
Mon Feb 18 13:06:52 2019 local2.info chat[2219]: send (ATD*99#^M)
Mon Feb 18 13:06:52 2019 local2.info chat[2219]: expect (CONNECT)
Mon Feb 18 13:06:52 2019 local2.info chat[2219]: ^M
Mon Feb 18 13:06:52 2019 local2.info chat[2219]: ATD*99#^M^M
Mon Feb 18 13:06:52 2019 local2.info chat[2219]: CONNECT
Mon Feb 18 13:06:52 2019 local2.info chat[2219]: -- got it
Mon Feb 18 13:06:52 2019 local2.info chat[2219]: send ( ^M)
Mon Feb 18 13:06:52 2019 daemon.info pppd[2142]: Serial connection
established.
Mon Feb 18 13:06:52 2019 kern.info kernel: [ 37.763727] 3g-wanb:
renamed from ppp0
[...]
Mon Feb 18 13:06:52 2019 daemon.info pppd[2142]: Using interface 3g-wanb
Mon Feb 18 13:06:52 2019 daemon.notice pppd[2142]: Connect: 3g-wanb <-->
/dev/ttyUSB1

I'm going to have to spend much of this afternoon on boring domestic
chores (but, hey, at least I won't have to make a round trip of 100
miles to Dingwall tomorrow, we've *at last* managed to persuade Tesco to
deliver to this area now!). I may be able to give it some more time later.

Thanks for the ongoing help.

[MikeS]

On 18/02/2019 15:23, Java Jive wrote:
> First, let me thank Chronos & Andy for their continuing help ...
>
> On 18/02/2019 07:18, Chronos wrote:
>>
>> On Mon, 18 Feb 2019 00:27:27 +0000
>> Java Jive <ja...@evij.com.invalid> wrote:
>>>
>>>     Huawei E3372s
>>
>> Yes, that's extremely important. Yours is the variant which appears to
>> be a serial modem, hence the "s" suffix, and accepts Hayes AT control
>> commands rather than appearing as a virtual NATted NIC.
>>
>>> ... but still no modem visible in either ifconfig or the GUI.
>>
>> No, there won't be. The WANx interface won't appear until pppd is
>> running and connected to the APN. You need luci-proto-3g
>
> Successfully installed.
>
>

> Next I tried ...
>     option device '/dev/ttyUSB1'
> ... but, although it connects as follows, it's treacle slow, and
> unreliable:
>

> I'm going to have to spend much of this afternoon on boring domestic
> chores (but, hey, at least I won't have to make a round trip of 100
> miles to Dingwall tomorrow, we've *at last* managed to persuade Tesco to
> deliver to this area now!).  I may be able to give it some more time later.
>
> Thanks for the ongoing help.

Sorry if this is so obvious you already did it but have you tried
installing the Huawei E3372s on a Windows machine to see if it and your
SIM work properly with a reliable 3G or 4G connection at your location?

[Java Jive]

On 18/02/2019 16:35, MikeS wrote:
>
> Sorry if this is so obvious you already did it but have you tried
> installing the Huawei E3372s on a Windows machine to see if it and your
> SIM work properly with a reliable 3G or 4G connection at your location?

Yes, as already described upthread.

[Andy Burns]

Java Jive wrote:

> Mon Feb 18 13:06:52 2019 daemon.info pppd[2142]: Serial connection
> established.
> Mon Feb 18 13:06:52 2019 kern.info kernel: [   37.763727] 3g-wanb:
> renamed from ppp0
> [...]
> Mon Feb 18 13:06:52 2019 daemon.info pppd[2142]: Using interface 3g-wanb
> Mon Feb 18 13:06:52 2019 daemon.notice pppd[2142]: Connect: 3g-wanb <-->
> /dev/ttyUSB1

So you do have some form of 3G connection working, if not
satisfactorily? I'll have another try ...

[Java Jive]

Don't be too hasty, that seems to have been a one-off, I've not got it
to work since, not even in the DrayTek or a PC. As previously posted, I
had it working in a PC (XP) two days ago and was measuring download
speeds between 10 & 20Mbps, but when I tried in that same PC today, it
crawling along at ~1Mbps. Next I tried it in both my W7 PCs, but
neither recognise the drivers for it any more, even though it was
installed on both when the build was first created. A search revealed that:
:-( Many others have the same problem!
:-( Huawei's site has no drivers at all, let alone updates!

So, all in all, I'm getting thoroughly hacked off. There are a number
of things I need to understand, but can't find solid evidence about:

1) Why are there two ttyUSBx devices, not one?

Is it:
? One is command/control channel, other is data channel?
? One is LTE, other is legacy 2 or 3G?
? Some other reason entirely?

2) How Linux is supposed to bring up a serial modem from boot? I mean
every step involved, because it seems likely that at least one is being
missed out. For example, on this page ...

https://techship.com/faq/how-to-activate-the-data-connection-for-huawei-cellular-modules-over-the-usb-network-interface-in-linux/

... which steps manually through the process, it cites the first step as
being the command ...
ip link set dev usb0 up
... though in fact this gives an error about being usb0 not being found.
However, if I change it to ...
ip link set dev wwan0 up
... it works silently without error. If, with wanb in stopped, I then
connect to ttyUSB0 ...

picocom /dev/ttyUSB0

... every few seconds there is echoed a message of the form ...

^HCSQ:"WCDMA",32,18,37

... but if wanb is not stopped, the attempt to use picocom freezes ad
has to be aborted with <Ctrl-A><Ctrl-X>, and logread shows a load of
broken pipe messages. Furthermore, with wanb set to use ttyUSB0, if I
add the above ip link command to ...
/etc/rc.local
... and reboot, logread no longer shows the LCP dropped message, but
there is still no connection, and the GUI shows 'PIN not recognised!",
which is an erroneous message, because logread shows that in fact it is,
so the error lies elsewhere in the 3g.chat dialogue or immediately
afterwards.

And talking about steps in the boot process, how come the if link
command works at all, I'm not aware of any file defining wwan0 anymore
than there is one defining usb0, so why does the latter fail but the
former apparently succeed?

Yours confusedly ... but thanks for your continued help.

[Andy Burns]

Java Jive wrote:

> 1)    Why are there two ttyUSBx devices, not one?
>
> Is it:
>     ?    One is command/control channel, other is data channel?

I think it's along those lines

> 2)    How Linux is supposed to bring up a serial modem from boot?   I
> mean every step involved, because it seems likely that at least one is
> being missed out.  For example, on this page ...

I know openwrt has to be "cut down" to fit small devices, but it's
annoying that on fedora the huawei modem "just works" using modemmanager

> ... every few seconds there is echoed a message of the form ...
>     ^HCSQ:"WCDMA",32,18,37

I think that's signal strength info

[MikeS]

On 19/02/2019 19:04, Java Jive wrote:
> On 19/02/2019 18:00, Andy Burns wrote:
>> Java Jive wrote:

> Don't be too hasty, that seems to have been a one-off, I've not got it
> to work since, not even in the DrayTek or a PC.  As previously posted, I
> had it working in a PC (XP) two days ago and was measuring download
> speeds between 10 & 20Mbps, but when I tried in that same PC today, it
> crawling along at ~1Mbps.  Next I tried it in both my W7 PCs, but
> neither recognise the drivers for it any more, even though it was
> installed on both when the build was first created.  A search revealed
> that:
>     :-(    Many others have the same problem!
>     :-(    Huawei's site has no drivers at all, let alone updates!
>

You can download numerous driver versions here for every Windows from XP
to 10:
https://huaweidrivers.com/huawei-e3372/

I would keep as separate issues whether the modem does/doesn't work and
the connection speed.

Over many years using O2 and Vodafone 3G dongles (interchangeably as
provided by employer) I found both showed wide variations in speed even
at the same location. Had two to increase the chance of a decent
connection at any given time/place.

The exact location (sometimes literally within a few inches) indoors is
also critical. I had the two TP-Link 3G routers mentioned earlier partly
as broadband replacements but also to allow optimum location of the dongle.

[Java Jive]

On 19/02/2019 20:46, MikeS wrote:
>
> On 19/02/2019 19:04, Java Jive wrote:
>>
>>      :-(    Huawei's site has no drivers at all, let alone updates!
>>
> You can download numerous driver versions here for every Windows from XP
> to 10:
> https://huaweidrivers.com/huawei-e3372/

Links eventually lead to porn site.

> I would keep as separate issues whether the modem does/doesn't work and
> the connection speed.

Perhaps, but right now I'm worried that pissing about in OpenWRT has
altered the configuration of the modem in some semi-permament way, as
it's not reached a decent speed since two days ago.

[MikeS]

On 19/02/2019 19:04, Java Jive wrote:

> On 19/02/2019 18:00, Andy Burns wrote:
>> Java Jive wrote:
>
> So, all in all, I'm getting thoroughly hacked off.  There are a number
> of things I need to understand, but can't find solid evidence about:
>
> 1)    Why are there two ttyUSBx devices, not one?
>
> Is it:
>     ?    One is command/control channel, other is data channel?
>     ?    One is LTE, other is legacy 2 or 3G?
>     ?    Some other reason entirely?
>

Not sure if it is the same issue but ...

One of the Vodafone supplied dongles over the years was a Huawei K4511
which I installed on Win XP. This created two network connections:
* A Local Area Connection
* A Mobile Broadband DUN

The DUN installation always utilised several COM ports which I tested
using AT command strings with a comms utility. As you noted some of
these are control channels, others invoke a response from the mobile
network cell. Switching between 2G, Edge and 3G was always automatic by
the system (on the same port).

I always used the (fake) "dialup" which seemed to connect much faster
and more reliably. I cannot remember what it was but I "dialed" with a
short "phone number" like *99# and made sure the DUN connectoid was set
to the correct COM port as displayed in the modem properties when the
dongle was inserted.

[MikeS]

Try this URL instead:
https://huawei-drivers.ru/huawei-e3372-driver-windows-download.html
I just downloaded one so it does work:
6-HUAWEI_Driver_5.05.02.00.rar (~5MB)

[Andy Burns]

Java Jive wrote:

> Don't be too hasty, that seems to have been a one-off, I've not got it
> to work since, not even in the DrayTek or a PC.

Well I've plugged mine into the HH5a and it hasn't paniced the USB
driver, so that's progress from a year ago

>  As previously posted, I
> had it working in a PC (XP) two days ago and was measuring download
> speeds between 10 & 20Mbps, but when I tried in that same PC today, it
> crawling along at ~1Mbps.

The colour of the LED indicates the type of connection (3G/4G/whatver)

cyan is best (I think)

[Andy Burns]

Andy Burns wrote:

> Java Jive wrote:
>
>> Don't be too hasty, that seems to have been a one-off, I've not got it
>> to work since, not even in the DrayTek or a PC.
>
> Well I've plugged mine into the HH5a and it hasn't paniced the USB
> driver, so that's progress from a year ago

And I can run "ifup LTE" and "ifdown LTE" without problems, it goes
through the motions of sending Hayes commands, and then fails to get an
IP addr on the LTE interface

Tue Feb 19 22:04:18 2019 daemon.notice netifd: Interface 'LTE' is
setting up now
Tue Feb 19 22:04:20 2019 daemon.info dnsmasq-dhcp[2700]:
DHCPREQUEST(br-lan) 192.168.1.95 00:c0:b7:d1:02:68
Tue Feb 19 22:04:20 2019 daemon.info dnsmasq-dhcp[2700]: DHCPACK(br-lan)
192.168.1.95 00:c0:b7:d1:02:68 ups
Tue Feb 19 22:04:21 2019 daemon.notice netifd: LTE (12508): sending -> AT
Tue Feb 19 22:04:21 2019 daemon.notice netifd: LTE (12508): sending -> ATZ
Tue Feb 19 22:04:22 2019 daemon.notice netifd: LTE (12508): sending -> ATQ0
Tue Feb 19 22:04:22 2019 daemon.notice netifd: LTE (12508): sending -> ATV1
Tue Feb 19 22:04:23 2019 daemon.notice netifd: LTE (12508): sending -> ATE1
Tue Feb 19 22:04:24 2019 daemon.notice netifd: LTE (12508): sending ->
ATS0=0
Tue Feb 19 22:04:24 2019 daemon.notice netifd: LTE (12508): sending ->
AT+CGDCONT=1,"IP","3internet"
Tue Feb 19 22:04:25 2019 daemon.notice netifd: LTE (12508): Configuring
modem
Tue Feb 19 22:04:25 2019 daemon.notice netifd: LTE (12508): Setting mode
Tue Feb 19 22:04:25 2019 daemon.notice netifd: LTE (12508): sending ->
AT^SYSCFGEX="00",3fffffff,2,4,7fffffffffffffff,,
Tue Feb 19 22:04:26 2019 daemon.notice netifd: LTE (12508): Starting
network LTE
Tue Feb 19 22:04:26 2019 daemon.notice netifd: LTE (12508): Connecting modem
Tue Feb 19 22:04:27 2019 daemon.notice netifd: LTE (12508): sending ->
AT^NDISDUP=1,1,"3internet"
Tue Feb 19 22:04:28 2019 daemon.notice netifd: LTE (12508): Setting up wwan0
Tue Feb 19 22:04:28 2019 daemon.notice netifd: Interface 'LTE' is now up
Tue Feb 19 22:04:28 2019 daemon.notice netifd: Network device 'wwan0'
link is up
Tue Feb 19 22:04:28 2019 daemon.notice netifd: Network alias 'wwan0'
link is up
Tue Feb 19 22:04:28 2019 daemon.notice netifd: Interface 'LTE_4' is enabled
Tue Feb 19 22:04:28 2019 daemon.notice netifd: Interface 'LTE_4' has
link connectivity
Tue Feb 19 22:04:28 2019 daemon.notice netifd: Interface 'LTE_4' is
setting up now
Tue Feb 19 22:04:28 2019 daemon.notice netifd: LTE_4 (12578): udhcpc:
started, v1.28.4
Tue Feb 19 22:04:28 2019 daemon.notice netifd: LTE_4 (12578): udhcpc:
sending discover
Tue Feb 19 22:04:29 2019 daemon.info odhcpd[1290]: Using a RA lifetime
of 0 seconds on br-lan
Tue Feb 19 22:04:30 2019 user.notice firewall: Reloading firewall due to
ifup of LTE (wwan0)
Tue Feb 19 22:04:31 2019 daemon.notice netifd: LTE_4 (12578): udhcpc:
sending discover
Tue Feb 19 22:04:34 2019 daemon.notice netifd: LTE_4 (12578): udhcpc:
sending discover


Tue Feb 19 22:04:37 2019 daemon.notice netifd: LTE (12724): Stopping
network LTE
Tue Feb 19 22:04:37 2019 daemon.notice netifd: LTE_4 (12578): udhcpc:
received SIGTERM
Tue Feb 19 22:04:37 2019 daemon.notice netifd: Interface 'LTE_4' is now down
Tue Feb 19 22:04:37 2019 daemon.notice netifd: Network alias '' link is down
Tue Feb 19 22:04:37 2019 daemon.notice netifd: Interface 'LTE_4' has
link connectivity loss
Tue Feb 19 22:04:37 2019 daemon.notice netifd: Interface 'LTE_4' is disabled
Tue Feb 19 22:04:38 2019 daemon.notice netifd: LTE (12724): sending ->
AT^NDISDUP=1,0
Tue Feb 19 22:04:38 2019 daemon.info odhcpd[1290]: Using a RA lifetime
of 0 seconds on br-lan
Tue Feb 19 22:04:38 2019 daemon.notice netifd: LTE (12724): Command
failed: Permission denied
Tue Feb 19 22:04:38 2019 daemon.notice netifd: Interface 'LTE' is now down

[Andy Burns]

Java Jive wrote:

> but right now I'm worried that pissing about in OpenWRT has altered the
> configuration of the modem in some semi-permament way

Give it an AT&F through minicom.

[Java Jive]

On 19/02/2019 21:33, MikeS wrote:
>
> Try this URL instead:
> https://huawei-drivers.ru/huawei-e3372-driver-windows-download.html
> I just downloaded one so it does work:
> 6-HUAWEI_Driver_5.05.02.00.rar (~5MB)

These drivers aren't recognised by W7 either, and therefore don't solve
this new problem which has transpired since I first built the Windows
image on this PC, when it was working.

[Java Jive]

On 17/02/2019 15:39, Chronos wrote:
>
> I wonder if Virgin's "unlimited" actually means "terms and conditions,
> including a FUP, apply and your kneecaps may be at risk if you exceed
> mobe levels of data" which would be pretty much standard for cheap
> deals from sh^H^Hmobile networks, especially virtual ones. That could
> mean a traffic profile filter kicking in.

Earlier this afternoon I spent about an hour on my mobile to Virgin's
Helpdesk. Got a helpful guy who confirmed:

:-) That I am not a victim of traffic-profiling or any other block.
Apparently there *is* a reasonable use limit, but it's of the order of
magnitude of 2TB, and therefore with my projected usage I'm unlikely
ever to reach that in practice.

:-) As per the recent finding by Ofcom, which was linked within the
last week from uk.telecom.mobile by Martin Nicholas in a thread entitled
'A SIM is a SIM is a SIM', their SIMS are device agnostic, and should
work in any compliant device.

Furthermore, I've just removed the SIM from the dongle and put it in my
tablet, and using mobile data have achieved the following results from
speedtest.net:
41ms, 37.73Mbps, 1.9Mbps

So it's not the network, and it's not the SIM, but I'm beginning to
think hard thoughts about the dongle - next I'll try Andy's suggestion
for resetting it elsewhere in this thread.

[Java Jive]

Seemingly no difference, but thanks anyway.

[Andy Burns]

Chronos wrote:

> a quick DDG reveals many hair pulling problems
> with this dongle if one is trying to use it on anything other than
> Windows with the drivers embedded into its virtual CD.

Having flashed my E3372h to be an E3372s (search for "needle method") it
is literally plug and play with Fedora using NetworkManager and/or
ModemManager.

[Andy Burns]

Java Jive wrote:

> Andy Burns wrote:
>
>> So you do have some form of 3G connection working, if not
>> satisfactorily?  I'll have another try ...
>
> Don't be too hasty, that seems to have been a one-off

WooHoo success!

From my previous attempts I was using /dev/ttyUSB1 as the device for
the E3372s which got as far as "dialling" but udhcpd never received an
IP address, changed it to /dev/ttyUSB0 and all is good.

I'm not using the mwan3 load balancing at present, so have to manually
bring up the LTE interface on demand.

"something" got fixed in the dwc2 USB driver in the last year that means
I no longer get the panic I was seeing

[Java Jive]

On 22/02/2019 12:21, Andy Burns wrote:
>
> WooHoo success!
>
> From my previous attempts I was using /dev/ttyUSB1 as the device for
> the E3372s which got as far as "dialling" but udhcpd never received an
> IP address, changed it to /dev/ttyUSB0 and all is good.
>
> I'm not using the mwan3 load balancing at present, so have to manually
> bring up the LTE interface on demand.
>
> "something" got fixed in the dwc2 USB driver in the last year that means
> I no longer get the panic I was seeing

Congratulations!

I've got my stick working again on an XP PC and when plugged into my
DrayTek (the one with the dead WiFi). So it looks like the right time
to try it again in the BTHH5a. I did a factory reset on that yesterday,
so could you confirm the exact steps needed from there to get the Huawei
E3372s working?

[Andy Burns]

Java Jive wrote:

> I've got my stick working again on an XP PC and when plugged into my
> DrayTek (the one with the dead WiFi).  So it looks like the right time
> to try it again in the BTHH5a.  I did a factory reset on that yesterday,
> so could you confirm the exact steps needed from there to get the Huawei
> E3372s working?

The additional packages I install, some of which bring in further
dependencies, some may be unnecessary.
luci-proto-ncm
usb-modeswitch
comgt-ncm
kmod-usb-net-huawei-cdc-ncm
kmod-usb-serial-wwan
kmod-usb-serial-wwan
kmod-usb-serial-option

The stanza for my LTE interface from /etc/config/network

config interface 'LTE'
option ifname 'wwan0'
option proto 'ncm'
option mode 'auto'
option apn '3internet'
option ipv6 'auto'
option delegate '0'
option skipinit '1'
option peerdns '0'
option device '/dev/ttyUSB0'
option pdptype 'IP'
option auto '0'

If you prefer to configure via the GUI, I could take some screenshots.

Place the LTE interface in the wan zone of the firewall, along with the
PPPoE-wan interface (named WAN1 in my case, along with WAN0 to WAN7
which are additional IP addresses specified with /32 masks which lets me
use all eight of them rather than just six using a /29 mask)

[Andy Burns]

Andy Burns wrote:

> The stanza for my LTE interface from /etc/config/network

And the output of logread, following an "ifup LTE"

Fri Feb 22 18:54:11 2019 daemon.notice netifd: Interface 'LTE' is
setting up now
Fri Feb 22 18:54:14 2019 daemon.notice netifd: LTE (3874): sending -> AT
Fri Feb 22 18:54:14 2019 daemon.notice netifd: LTE (3874): sending -> ATZ
Fri Feb 22 18:54:15 2019 daemon.notice netifd: LTE (3874): sending -> ATQ0
Fri Feb 22 18:54:15 2019 daemon.notice netifd: LTE (3874): sending -> ATV1
Fri Feb 22 18:54:16 2019 daemon.notice netifd: LTE (3874): sending -> ATE1
Fri Feb 22 18:54:17 2019 daemon.notice netifd: LTE (3874): sending -> ATS0=0
Fri Feb 22 18:54:17 2019 daemon.notice netifd: LTE (3874): sending ->
AT+CGDCONT=1,"IP","3internet"
Fri Feb 22 18:54:18 2019 daemon.notice netifd: LTE (3874): Configuring modem
Fri Feb 22 18:54:18 2019 daemon.notice netifd: LTE (3874): Setting mode
Fri Feb 22 18:54:18 2019 daemon.notice netifd: LTE (3874): sending ->
AT^SYSCFGEX="00",3fffffff,2,4,7fffffffffffffff,,
Fri Feb 22 18:54:19 2019 daemon.notice netifd: LTE (3874): Starting
network LTE
Fri Feb 22 18:54:19 2019 daemon.notice netifd: LTE (3874): Connecting modem
Fri Feb 22 18:54:20 2019 daemon.notice netifd: LTE (3874): sending ->
AT^NDISDUP=1,1,"3internet"
Fri Feb 22 18:54:21 2019 daemon.notice netifd: LTE (3874): Setting up wwan0
Fri Feb 22 18:54:21 2019 daemon.notice netifd: Interface 'LTE' is now up
Fri Feb 22 18:54:21 2019 daemon.notice netifd: Network device 'wwan0'
link is up
Fri Feb 22 18:54:21 2019 daemon.notice netifd: Network alias 'wwan0'
link is up
Fri Feb 22 18:54:21 2019 daemon.notice netifd: Interface 'LTE_4' is enabled
Fri Feb 22 18:54:21 2019 daemon.notice netifd: Interface 'LTE_4' has
link connectivity
Fri Feb 22 18:54:21 2019 daemon.notice netifd: Interface 'LTE_4' is
setting up now
Fri Feb 22 18:54:21 2019 daemon.notice netifd: LTE_4 (3927): udhcpc:
started, v1.28.4
Fri Feb 22 18:54:21 2019 user.notice firewall: Reloading firewall due to
ifup of LTE (wwan0)
Fri Feb 22 18:54:21 2019 daemon.notice netifd: LTE_4 (3927): udhcpc:
sending discover
Fri Feb 22 18:54:22 2019 daemon.info odhcpd[1662]: Using a RA lifetime

of 0 seconds on br-lan

Fri Feb 22 18:54:24 2019 daemon.notice netifd: LTE_4 (3927): udhcpc:
sending discover
Fri Feb 22 18:54:24 2019 daemon.notice netifd: LTE_4 (3927): udhcpc:
sending select for 188.30.53.248
Fri Feb 22 18:54:24 2019 daemon.notice netifd: LTE_4 (3927): udhcpc:
lease of 188.30.53.248 obtained, lease time 518400
Fri Feb 22 18:54:24 2019 daemon.notice netifd: Interface 'LTE_4' is now up

[Java Jive]

On 22/02/2019 19:03, Andy Burns wrote:
> Andy Burns wrote:
>
>> The stanza for my LTE interface from /etc/config/network
>
> And the output of logread, following an "ifup LTE"

Thanks Andy, I'll get stuck into that this evening and report back!

[Java Jive]

Success here too! A particular thank you to Andy for posting his
excerpts from /etc/config/network and logread, but also not forgetting
Chronos' help as well.

Now installed as the live system, with a speed test on this PC giving:
49ms, 24Mbps (~20x landline), 3Mbps (12x)

I'll check it for reliability over the next few overnight GiP downloads
before finally telling my ISP to get lost.

I do have a couple of problems remaining though ...

1) Bedroom upstairs is connected to the rest of the LAN by a Cisco
WRT320n with a DD-WRT build configured as a client bridge. It locks on
to the HH5a's 2.4 signal, and appears in the HH5a's client list, but the
QNAP NMP-1000 attached to it still cannot get an NTP time signal to set
its clock, just as with the DV2830n, but much more seriously nothing
else can cross the client bridge either. The QNAP and the rest of the
LAN can't see each other, not even by IP, which makes the existence of
the wireless client bridge useless. It seems to be a firewall problem
but the obvious option, to isolate WiFi clients, is *disabled* on both
frequencies, so I don't really know what else to check. This is a
serious problem for me.

2) It doesn't seem to be possible to have a separate open but isolated
WiFi SSID for visitors, but as I don't have many people calling round,
that's not so much of a problem.

[Andy Burns]

Java Jive wrote:

> I do have a couple of problems remaining though ...

> nothing else can cross the client bridge either.

Have never needed wifi bridging, so can't comment

> It seems to be a firewall problem

enable per-zone firewall logging, and see what shows up

> 2)    It doesn't seem to be possible to have a separate open but
> isolated WiFi SSID for visitors

You can create multiple SSIDs per radio, and a guest zone in the
firewall, allowed to see the wan but not lan zones (probably you need a
dhcp rule on firewall)

[Java Jive]

On 24/02/2019 17:49, Andy Burns wrote:
> Java Jive wrote:
>
>> I do have a couple of problems remaining though ...
>> nothing else can cross the client bridge either.
>
> Have never needed wifi bridging, so can't comment
>
>> It seems to be a firewall problem
>
> enable per-zone firewall logging, and see what shows up

Can't see how to do that, but examination of the system log I think has
told me what is going wrong. If the behaviour of a PC beyond a similar
client bridge (yes, I've managed to recover the other Cisco WRT320n this
evening) is anything to go by, the QNAP is not getting an IP over the
client bridge.

>> 2)    It doesn't seem to be possible to have a separate open but
>> isolated WiFi SSID for visitors
>
> You can create multiple SSIDs per radio, and a guest zone in the
> firewall, allowed to see the wan but not lan zones (probably you need a
> dhcp rule on firewall)

Again, I'll have to research how to do that.

Thanks for the suggestions.

[Java Jive]

On 24/02/2019 23:13, Java Jive wrote:
>
> Can't see how to do that, but examination of the system log I think has
> told me what is going wrong.  If the behaviour of a PC beyond a similar
> client bridge (yes, I've managed to recover the other Cisco WRT320n this
> evening) is anything to go by, the QNAP is not getting an IP over the
> client bridge.

Perhaps I should've included an excerpt:

Mon Feb 25 01:05:48 2019 daemon.info dnsmasq-dhcp[16311]:
DHCPDISCOVER(br-lan) 169.254.51.63 00:11:43:44:fe:da
Mon Feb 25 01:05:48 2019 daemon.info dnsmasq-dhcp[16311]:
DHCPOFFER(br-lan) 192.168.1.105 00:11:43:44:fe:da
Mon Feb 25 01:05:48 2019 daemon.info dnsmasq-dhcp[16311]:
DHCPDISCOVER(br-lan) 169.254.51.63 00:11:43:44:fe:da
Mon Feb 25 01:05:48 2019 daemon.info dnsmasq-dhcp[16311]:
DHCPOFFER(br-lan) 192.168.1.105 00:11:43:44:fe:da

So it seems a DHCP request from the PC is being received at the router
via the client bridge, but the PC doesn't appear to be receiving the
router's offer back across the client bridge. Not sure why that would
be, but it must be something to do with the router, because it's never
been a problem to connect this PC like that with any other router -
I've done it many times before, because the client bridge is n, while
the PC's WiFi connection is only g.

[Andy Burns]

Java Jive wrote:

> Andy Burns wrote:
>

>> enable per-zone firewall logging, and see what shows up
>
> Can't see how to do that

network, firewall, zones, edit, advanced settings, enable logging

[Nick Leverton]

In article <q4vfk7$1645$1...@gioia.aioe.org>,

Java Jive <ja...@evij.com.invalid> wrote:
>On 24/02/2019 23:13, Java Jive wrote:
>>
>> Can't see how to do that, but examination of the system log I think has
>> told me what is going wrong.  If the behaviour of a PC beyond a similar
>> client bridge (yes, I've managed to recover the other Cisco WRT320n this
>> evening) is anything to go by, the QNAP is not getting an IP over the
>> client bridge.
>
>Perhaps I should've included an excerpt:
>
>Mon Feb 25 01:05:48 2019 daemon.info dnsmasq-dhcp[16311]:
>DHCPDISCOVER(br-lan) 169.254.51.63 00:11:43:44:fe:da
>Mon Feb 25 01:05:48 2019 daemon.info dnsmasq-dhcp[16311]:
>DHCPOFFER(br-lan) 192.168.1.105 00:11:43:44:fe:da
>Mon Feb 25 01:05:48 2019 daemon.info dnsmasq-dhcp[16311]:
>DHCPDISCOVER(br-lan) 169.254.51.63 00:11:43:44:fe:da
>Mon Feb 25 01:05:48 2019 daemon.info dnsmasq-dhcp[16311]:
>DHCPOFFER(br-lan) 192.168.1.105 00:11:43:44:fe:da
>
>So it seems a DHCP request from the PC is being received at the router
>via the client bridge, but the PC doesn't appear to be receiving the
>router's offer back across the client bridge.

I'd hazard a guess that it may be to do with Proxy ARP or lack thereof.
Compare the MACs in the packets on the LAN side in the working and
non-working cases, see if one of the client bridges is putting its own
MAC so that it gets packets for its attached device, and perhaps the
other isn't ? If not that then I don't know, my only time tangling with
configuring Ciscos was a frustrating and unpleasant experience ...

Nick
--
"The Internet, a sort of ersatz counterfeit of real life"
-- Janet Street-Porter, BBC2, 19th March 1996

[Java Jive]

Thanks, but that doesn't generate any new messages that I can see.

I've now proved that it's DHCP and seemingly DHCP *only* that is the
problem. If I give a target test PC beyond a client-bridge a fixed IP
in the correct LAN subnet, and set the HH5a as the gateway and DNS
server, then everything works - in both directions I can ping by name
and access shares.

I think OpenWRT must be somewhat confused by this use of wireless as a
client-bridge - where effectively the wireless link replaces a length
of cable that would be too awkward or expensive to hard wire - because
this page suggests that it isn't possible ...

https://oldwiki.archive.openwrt.org/doc/recipes/bridgedclient

... whereas I've been using these two Cisco LinkSys WRT320ns with DD-WRT
builds in client-bridge mode for ages with either no or only minor
problems, as follows:

Access Point Router Client-Bridge Specific Issues
=================== =============================
Cisco LinkSys WRT320n None
Cisco LinkSys WAG320n None, but no local DNS on LAN
DrayTek Vigor 2830n Restricted internet access beyond it,
and no local DNS on LAN
Technicolor TG582n None, but no local DNS on LAN

I guess the difference is that DD-WRT know what needs to be done to make
this work, but OpenWRT do not.

However that may be, I'm still left with the problem of why the DHCP
offer is not getting back to the target PC.

[Java Jive]

Thanks, but if you look at my reply of a few minutes ago to Andy, I
think that can be discounted, because the client bridges have worked for
ages with various different routers as the originating access point.
The only thing that's different here is that the originating access
point is a HH5a with an OpenWRT build, so that combination must be where
the problem lies.

[Andy Burns]

Nick Leverton wrote:

> Java Jive wrote:
>
>> Mon Feb 25 01:05:48 2019 daemon.info dnsmasq-dhcp[16311]:
>> DHCPDISCOVER(br-lan) 169.254.51.63 00:11:43:44:fe:da
>> Mon Feb 25 01:05:48 2019 daemon.info dnsmasq-dhcp[16311]:
>> DHCPOFFER(br-lan) 192.168.1.105 00:11:43:44:fe:da
>> Mon Feb 25 01:05:48 2019 daemon.info dnsmasq-dhcp[16311]:
>> DHCPDISCOVER(br-lan) 169.254.51.63 00:11:43:44:fe:da
>> Mon Feb 25 01:05:48 2019 daemon.info dnsmasq-dhcp[16311]:
>> DHCPOFFER(br-lan) 192.168.1.105 00:11:43:44:fe:da
>>
>> So it seems a DHCP request from the PC is being received at the router
>> via the client bridge, but the PC doesn't appear to be receiving the
>> router's offer back across the client bridge.

When I see "direct" discover/offer there is no IP addr associated with
the discover (or probably the logging suppresses 0.0.0.0 as a source IP
addr)

Mon Feb 25 03:09:08 2019 daemon.info dnsmasq-dhcp[2632]:
DHCPDISCOVER(br-lan) 54:60:09:ec:e7:aa
Mon Feb 25 03:09:08 2019 daemon.info dnsmasq-dhcp[2632]:
DHCPOFFER(br-lan) 192.168.1.194 54:60:09:ec:e7:aa
Mon Feb 25 03:09:08 2019 daemon.info dnsmasq-dhcp[2632]:
DHCPREQUEST(br-lan) 192.168.1.194 54:60:09:ec:e7:aa
Mon Feb 25 03:09:08 2019 daemon.info dnsmasq-dhcp[2632]: DHCPACK(br-lan)
192.168.1.194 54:60:09:ec:e7:aa Chromecast-Audio

but with charles' example there is an APIPA address, is that an address
of the wrt320 bridge, presumably it ought to have a 'real' address...

[Java Jive]

It's the current or last IP address of the PC. 169.254.*.* is an
address in the link local range after a previous attempt at ...
ipconfig /renew
... had timed out, leaving the PC with that self-assigned IP address in
the link local range. Similarly, if I temporarily give the PC a fixed
IP of 192.168.1.8, run some tests, and them set it back to receiving an
IP via DHCP, the next attempt at DHCP dialogue that appears in the
system log on the router contains 192.168.1.8, and immediately after
booting the PC the first attempt at a dialogue contains the address 0.0.0.0.

This is a strange, contradictory situation. On the one hand, the fact
that these client bridges have worked with so many other routers acting
as the LAN's access point suggests strongly that the problem lies with
this particular combination of HH5a running OpenWRT, however the fact
that 'straight' both cabled and wireless clients get IP addresses from
it implies that the problem is with the client bridge!

AIUI, a DHCP dialogue begins with the client sending a request to IP
255.255.255.255 using UDP and port 67, and should receive back the offer
also to IP 255.255.255.255 via UDP but port 68. It's this second stage
that seems to fail.

[Java Jive]

On 25/02/2019 14:42, Java Jive wrote:
>
> ... whereas I've been using these two Cisco LinkSys WRT320ns with DD-WRT
> builds in client-bridge mode for ages with either no or only minor
> problems, as follows:
>
>     Access Point Router     Client-Bridge Specific Issues
>     ===================    =============================
>     Cisco LinkSys WRT320n    None
>     Cisco LinkSys WAG320n    None, but no local DNS on LAN
>     DrayTek Vigor 2830n    Restricted internet access beyond it,
>                 and no local DNS on LAN
>     Technicolor TG582n    None, but no local DNS on LAN

I forgot to add ...
Samsung SM-T719 Tablet in WiFi tethering mode None
... a neat trick for when your landline or other main broadband fails.
Set the client bridge router to lock onto the SSID of a phone or tablet
in WiFi tethering mode, connect one of its LAN ports to the WAN port of
your main LAN router (the WAN port should be set to pick up an IP via
DHCP, which it should do from the phone or tablet via the client bridge)
and thus you can use your phone or tablet to give temporary internet
access to every device on your LAN, without having to reconfigure any of
them individually to attach to the phone or tablet to do so.

[Java Jive]

Been a bit busy over the last day or so, but finally had a chance to
investigate this further. Here's a TCPDump to the console of the HH5a
as the test PC boots up the far side of the client-bridge (what follows
is anonymized, and is periodically repeated, but unchanging):

root@OpenWRT:~# tcpdump -i wlan1 udp port 68 -vv -X
01:23:03.553804 IP (tos 0x0, ttl 128, id 6, offset 0, flags [none],
proto UDP (17), length 328)
0.0.0.0.68 > 255.255.255.255.67: [udp sum ok] BOOTP/DHCP, Request
from 00:11:22:33:44:55 (oui Unknown), length 300,
xid 0x35e0515c, secs 7168, Flags [Broadcast] (0x8000)
Client-Ethernet-Address 00:11:22:33:44:55 (oui Unknown)
Vendor-rfc1048 Extensions
Magic Cookie 0x63825363
DHCP-Message Option 53, length 1: Discover
NOAUTO Option 116, length 1: Y
Client-ID Option 61, length 7: ether 00:11:22:33:44:55
Requested-IP Option 50, length 4: 192.168.xxx.yyy
Hostname Option 12, length 9: "Test-Host"
Vendor-Class Option 60, length 8: "MSFT 5.0"
Parameter-Request Option 55, length 11:
Subnet-Mask, Domain-Name, Default-Gateway, Domain-Name-Server
Netbios-Name-Server, Netbios-Node, Netbios-Scope,
Router-Discovery
Static-Route, Classless-Static-Route-Microsoft, Vendor-Option
Vendor-Option Option 43, length 2: 220.0
0x0000: 4500 0148 0006 0000 8011 39a0 0000 0000 E..H......9.....
0x0010: ffff ffff 0044 0043 0134 9e99 0101 0600 .....D.C.4......
0x0020: 35e0 515c 1c00 8000 0000 0000 0000 0000 5.Q\............
0x0030: 0000 0000 0000 0000 0011 2233 4455 0000 ..........CD....
0x0040: 0000 0000 0000 0000 0000 0000 0000 0000 ................
0x0050: 0000 0000 0000 0000 0000 0000 0000 0000 ................
0x0060: 0000 0000 0000 0000 0000 0000 0000 0000 ................
0x0070: 0000 0000 0000 0000 0000 0000 0000 0000 ................
0x0080: 0000 0000 0000 0000 0000 0000 0000 0000 ................
0x0090: 0000 0000 0000 0000 0000 0000 0000 0000 ................
0x00a0: 0000 0000 0000 0000 0000 0000 0000 0000 ................
0x00b0: 0000 0000 0000 0000 0000 0000 0000 0000 ................
0x00c0: 0000 0000 0000 0000 0000 0000 0000 0000 ................
0x00d0: 0000 0000 0000 0000 0000 0000 0000 0000 ................
0x00e0: 0000 0000 0000 0000 0000 0000 0000 0000 ................
0x00f0: 0000 0000 0000 0000 0000 0000 0000 0000 ................
0x0100: 0000 0000 0000 0000 6382 5363 3501 0174 ........c.Sc5..t
0x0110: 0101 3d07 0100 1143 44fe da32 04c0 a8xx ..=....CD..2....
0x0120: yy0c 0954 6573 742d 686f 7374 3c08 4d53 l..Test-Host<.MS
0x0130: 4654 2035 2e30 370b 010f 0306 2c2e 2f1f FT.5.07.....,./.
0x0140: 21f9 2b2b 02dc 00ff !.++....

[Andy Burns]

Java Jive wrote:

> root@OpenWRT:~# tcpdump -i wlan1 udp port 68 -vv -X

Might you be better off capturing from the br-lan interface, rather than
the wlanX interface that's a member of the bridge?

I think I'd rather see multiple copies of packets, than potentially miss
some of them ...

[Java Jive]

Yes, the above was always a first step. However it has the great
benefit of *proving* something that I already suspected strongly because
of the client-bridge working with other routers, that the problem does
indeed lie within this router, because the 'discover' packets are coming
into the wireless interface, but no 'offer' packets in response are
travelling out of it.

So now we know:

:-) The System Log shows 'offer' packets apparently being generated ...

:-( ... but they never get out of the router.

As you suggest, the next step is to chop up the internal path within the
router, to see if we can locate the fault more precisely, but it's
before br-lan, because substituting this in the command above gives
exactly the same output as for wlan1. However, substituting eth0 gives
*no* output whatsoever, whereas I had half expected to see *both* types
of packet passing. It seems my understanding is a little off the mark,
and I'll have to think some more about that result.

However, the early morning mist is clearing, the sun is shining, and I
have work to do outside, so I'll come back to this, later.

Thanks for your ongoing suggestions.

[Java Jive]

On 27/02/2019 12:43, Java Jive wrote:
>
> So now we know:
>
>     :-)    The System Log shows 'offer' packets apparently being
> generated ...
>
>     :-(    ... but they never get out of the router.
>
> As you suggest, the next step is to chop up the internal path within the
> router, to see if we can locate the fault more precisely, but it's
> before br-lan, because substituting this in the command above gives
> exactly the same output as for wlan1.  However, substituting eth0 gives
> *no* output whatsoever, whereas I had half expected to see *both* types
> of packet passing.  It seems my understanding is a little off the mark,
> and I'll have to think some more about that result.

I guess it just means that the 'offer' packet is going to a specific
port to which the requesting PC is connected, not the lan generally as I
had supposed.

A new discovery from examining /etc/config/firewall ...

config defaults
option syn_flood '1'
option input 'ACCEPT'
option output 'ACCEPT'
option forward 'REJECT'

config zone
option name 'lan'
option input 'ACCEPT'
option output 'ACCEPT'
option forward 'ACCEPT'
option network 'lan'
option log '1'

config zone
option name 'wan'
option input 'REJECT'
option output 'ACCEPT'
option forward 'REJECT'
option masq '1'
option mtu_fix '1'
option network 'WAN_ADSL WAN_Ethernet WAN_USB'

Note that in the lan zone, option network refers to itself, while in the
wan zone option network refers to the actual interfaces. Accordingly, I
tried setting the lan zone to option network 'br-lan' and then DHCP
works across the client bridge. Hooray! But, not hooray! Nothing was
able to access the internet ...

17:45:05 C:\TEMP>ping www.macfh.co.uk

Pinging www.macfh.co.uk [217.160.0.33] with 32 bytes of data:

Reply from 192.168.1.1: Destination port unreachable.
Reply from 192.168.1.1: Destination port unreachable.
Reply from 192.168.1.1: Destination port unreachable.
Reply from 192.168.1.1: Destination port unreachable.

Ping statistics for 217.160.0.33:
Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
Minimum = 0ms, Maximum = 0ms, Average = 0ms

17:45:16 C:\TEMP>ping 217.160.0.33

Pinging 217.160.0.33 with 32 bytes of data:

Reply from 192.168.1.1: Destination port unreachable.
Reply from 192.168.1.1: Destination port unreachable.
Reply from 192.168.1.1: Destination port unreachable.
Reply from 192.168.1.1: Destination port unreachable.

... so I had to undo the change ... Terribly frustrating ... As I
thought all along, the problem is obviously some slight misconfiguration
of the firewall, but I can't quite find out how to fix it.

[Andy Burns]

Java Jive wrote:

> Note that in the lan zone, option network refers to itself, while in the
> wan zone option network refers to the actual interfaces.

It's just that you have a zone and an interface both called "lan" but
there's no significance to that, the zone could just as easily be called
"internal"

[Java Jive]

Yes, and it's a bloody dog's dinner. In many untyped programming
languages, it is often considered good practice to clarify the type of
variable by prefixing the name, so
strVariable for a string,
intVariable for an integer,
objVariable for an object,
ptrVariable for a pointer,
etc.

A convention like that is required here, so anyone and everyone can tell
more easily what the hell is going on. Indeed, it may well be the lack
of such an understandable convention that originally led to the bug I'm
actually trying to solve!

[Java Jive]

The above point still stands, but as far as the 'bug' goes I have to eat
humble pie, as it was a misconfiguration by myself - somewhere in the
OpenWRT support it describes a bug using the WAN port where the MAC is
not applied properly, and they suggest setting one manually in the
advanced settings. I reasoned that the DSL port would be the next one
up from that of eth0, so added two for the WAN port, but it so happens
that this is the MAC of the WLAN. Changing the port assigned to the WAN
to eth0+1 has solved the problem.