New firmware with built in Torrent Client

[DougWhitt]

Hi,  I've had a DGND3700v1 gathering dust for a couple of years since I moved to BT Infinity and was provided with a Home Hub 5.  I've had some wifi issues recently and, as there have been some issues with Home Hub wifi, I wanted to confirm whether the issues were originating from the BT router.  During my online searches to investigate the issue I found this read and wondered if I could resurrect my DGND3700 and replace the Home Hub 5.

I've tried on and off over the last week but can't get it connected.  I initially updated the Firmware using the Annex A config file but the Internet LED stayed red, all other lights were lit as expected.  I then read in a thread (can't remember whether it was this one or another forum) that BT Infinity requires Annex B.  I, therefore, flashed the Annex B config file but still no joy!  With this config file the DSL LED blinks green and the Internet light is off.

Would anyone who is using the custom firmware on BT Infinity kindly share their settings?  I have tried:

Internet Setup: 

Does your Internet connection require a login?  YES 

Encapsulation:  PPPoE(PPP over Ethernet) 

Login:  bthomehub@btbroadband.com

Password:  BLANK

ADSL Settings: 

ISP:  Other 

Transfer Mode:  PTM 

DSL Mode:  VDSL2

• WAN1 was selected by default and the Enable This Interface box ticked

Multiplexing Method:  VC-Based

VPI:  0

VCI:  38

Use VLANID:  101

WAN Setup: 

WAN Preference:  Auto-Detect (I have also tried Must use DSL WAN)

Adavance Setup 2: 

Advanced xDSL Settings

DSL Modulation:  VDSL2

Everything else is at the default setting.

Any help would be much appreciated.

Thanks.

[Aircomms]

Hi,

I would like to know is it possible to use the current DNSmasq on the router with the lastest firmwire to run Split DNS

[Aircomms]

Is it possible to run this DNSmasq in the firmwire as a Split DNS.

If so how would I best configure this?

[burt35]

hi there been running this firmware for 5 months no problem woke up this morning internet not working but green light to say that it is working, tried old sky router which works. so  i thought i would do a factory reset and start again but now im stuck with a german 3800b genie firmware that i cant change for the life of me. ive tried flashing original firmwares and still keeps coming back to the german firmware. any tips help. thanks for your input.

[Aircomms]

Hi,

The only way to fix this is to wipe all settings restart and install version 1.0.0.12.

[DougWhitt]

@burt35, what worked for me when this happened was to select another language from the dropdown let the change complete, then select English and let the change complete. Sometimes I had to do this more than once, not sure if your router needs a internet connection during the change. If you do a Google search or go back in this thread there is an alternative solution but the method I've explained above worked for me before I found the thread solution.

[richud]

@burt35, telnet/ssh in, one of these three nvram settings controls the language, cant remember off top of my head, think unintuitively it the brs one.

[The language choice pulldown on the web gui does this also, dont know why some people seem to find it doesnt work]

param set gui_region=English
param set http_lang=en
param set first_brs_lang=English

param save

reboot

(dont forget your browser may be caching stuff too)

[richud]

I perhaps should add this again, was explained many pages ago I think...
If you start out with a 3700 there is no genie language setting. Then you flash with genie firmware. When it boots it looks for this setting, if it doesn't exist it sets it to english, so first time it ever boots it will set it to english. It then stays english until either you change it or you do a complete default reset. The defaults, as based on 3800 firmware is to be german. (I never figured out how to change this stock default). On reboots, as the value exists when it checks, it stays what its set to, hence German after a default rests.

[burt35]

thanks for the help guys tried dougs tip which worked got it back to normal still havnt tried it online yet got old sky router on for time being ill try it weekend. cheers.

[burt35]

back up and running now thought id let you know cheers.

[mauriva]

Sorry for my delay in writing...

About my question on this post about P2P clients and the DGND3700 slowing down: thank you richud for your answer!

I'm not an expert and I don't know so much about NAT table, but in the meantime I discovered something.

The P2P clients I use (emule and tixati) are launched from a server with Windows Server 2012 R2 as Operating System: especially emule seems to slow the modem.

But i I use the same client from my PC with Windows 10 Pro, all works fine.

So there is something wrong with Windows server 2012.

Can someone explain to me why this?

If I install Ubuntu server instead of Win Server I could have the same problems?

Many thanks!

[luxury1809]

Hello every one. I'm newbie

I'm using dgnd3700 v1. How to flash firmware from openwrt to stock firmware ? I don't know edit Remove the Netgear firmware header (first 65 bytes)

https://wiki.openwrt.org/toh/netgear/dgnd3700

 Can you help me ?

Please !

[Even_Loonger]

Hey 🙂

I'm absolout new with open vpn. I just want to create a save connection from outside to my home network, where a nas is atached. So what do i have to do? Open vpn is allready installed on my adroid device. Dont know, witch settings i have to use. There is a open vpn secrion under remote acess and a secomd one under advanced.

My route is a dgnd 3700vs with actual richuds firmware.

Greets an many thanks,

Phil

[ramjet303]

Hi. Richud

Have some questions re installing.

I am helping a friend and this firmware looks just right. The transfer performance on ntfs is just chronic.

Found some reviews which test file transfer speeds and ext2 looks to offer best performance.

(See  http://www.xbitlabs.com/articles/networking/display/netgear-wndr-3800_4.html#sect0).

I went to upgrade via web interface where netgear 1.0.48 is installed and using richud 04 2016 wndr3800 annex a  with chk extension it was  rejected and was wary as I do not want to brick it.

Information on dd wrt and open wrt sites put that for install one needs to first downgrade to netgear 1.0.16 so that the new (richud) software will then install.

Is that what needs to be done?  I have read a lot but I lack confidence and need to be sure.

Also if one was to want to revert (which is unlikely) to the original netgear software the openwrt

pages provide an explanation that headers need to be stripped off the netbear software in order to then

reinstall it. Does any one have experience of this?

The wndr3800 is with Optus in Australia as the provider and is annex a

Thanks in antcipation and especially for producing this advanced firmware.

Regards

ramjet303

[w3wilkes]

Can't say for the DD-WRT firmware, but for Richud's firmware I have gone back to stock once. For me the biggest issue going back to stock Netgear firmware was language. First, just install the stock 1.0.0.12, set language to German (which is what you will probably see displaying, but had to set and apply anyway), then set the language to English and Apply. Then go forward to stock  1.0.0.17. I will say that this was all a very long time ago for some issue I had, I was back on Richud's firmware in less than 2 weeks. I've been back on this firmware for well over a year and can't see going back to stock firmware for any reason now. I believe the last time my router was booted was due to a lighting storm that caused a power failure. Can't say before that, but it was probably a power failure. My experience is this is VERY stable firmware with lots of NICE features added. Really shows what this device woulda, shoulda, coulda been.

Oh, I use ext3 and it works just fine for network storage, don't use the media server, run scheduled backups from mine and my wife's PC to the router attached storage. I think you'll need to format your drive from a PC, I use Partition Wizard HE on Win10 for this.

[w3wilkes]

@richud, Had an interesting discovery today, it's just a nit though. Had a PC plugged into the WAN port which I've configured as a LAN port. When I look at the attached devices (NetBIOS) it shows as a Wireless device. Works fine, just a curiosity.

[jewelie]

Hi

Regarding @richud's 2016-04-10_3.1.22 firmware, is there any way to change the mount options for a connected USB device?

Unfortunately, the default linux kernel mount options for vfat partitions ("shortname=lower") breaks filename case compatibility rather badly for many things.

/media/Ntwk-Backup/tmp # touch TEST
/media/Ntwk-Backup/tmp # ls -l
-rwxrwxrwx    1 root     root             0 Oct  6 14:30 test

The most compatible version of the setting is generally "shortname=mixed", otherwise you can get all sorts of odd bugs, especially if you try to rsync.

Warm Regards

Julie

PS *AMAZING* firmware.  😄  I'm soooo impressed!

[jewelie]

Now I'm worried.  😞

Decided to run my config via GRC's ShieldsUp port testers and as long as miniDLNA is disabled, all tests pass.

However, if miniDLNA is enabled (whether or not uPnP is enabled) then the Shield's Up uPnP tester reports the miniDLNA uPnP being exposed to the WAN!

HELP!  Is this just a silly configuration error on my part or does anyone else using this as a VDSL modem and for DLNA media sharing see the same thing?

Obviously I'm disabling miniDLNA for now, but that's not a practical long term solution as that's part of why I bought the router in the first place.  😞

To test go to- www.grc.com -> Services -> Shields Up -> Proceed -> hit the orange uPnP test button 

[jewelie]

EDIT: I've investigated further...

This issue of the miniDLNA appearing on Internet only occurs after a device on the LAN has attempted to access the minidlna server in some way at least once since minidlna started up. Before that the service seems secure. After that, it starts responding to the wider internet. 😞

LOGS

Starting up. As you can see it's only, in theory, listening on the LAN interface-

[2016/04/10 00:00:12] minidlna.c:1030: warn: Starting ReadyDLNA version 1.1.5.
[2016/04/10 00:00:13] minidlna.c:1070: warn: HTTP listening on port 8200
[2016/04/10 00:00:13] getifaddr.c:338: info: Enabling interface 192.168.*.*/255.255.255.0
[2016/10/06 20:24:04] minidlna.c:1110: debug: Sending SSDP notifies

At this point the www.grc.com Shields Up! uPnP port test passes as clear, no problems.

Now, a device on the LAN accesses the media server (only needs to be once, and the device can be turned off and isolated from the network straight after)-

[2016/10/06 20:25:56] minissdp.c:696: debug: SSDP M-SEARCH from 192.168.*.*:24234 ST: urn:schemas-upnp-org:device:MediaServer:1, MX: 4, MAN: "ssdp:discover"
[2016/10/06 20:25:56] minissdp.c:257: debug: Sending M-SEARCH response to 192.168.*.*:24234 ST: urn:schemas-upnp-org:device:MediaServer:
[2016/10/06 20:25:56] minissdp.c:696: debug: SSDP M-SEARCH from 192.168.*.*:24234 ST: urn:schemas-upnp-org:device:MediaServer:1, MX: 4, MAN: "ssdp:discover"
...
[2016/10/06 20:25:56] minidlna.c:1266: debug: HTTP connection from 192.168.*.*:53597
[2016/10/06 20:25:56] minidlna.c:1266: debug: HTTP connection from 192.168.*.*:53598
[2016/10/06 20:25:56] clients.c:295: debug: Added client [**********/192.168.*.*/**:**:**:**:**] to cache slot 0.
[2016/10/06 20:25:56] upnphttp.c:880: debug: HTTP REQUEST: GET /rootDesc.xml HTTP/1.1
HOST: 192.168.*.1:8200
ACCEPT-ENCODING: deflate
ACCEPT-LANGUAGE: en-us
User-Agent: SEC_HHP_**************

[2016/10/06 20:25:56] upnphttp.c:1216: debug: HTTP RESPONSE: HTTP/1.1 200 OK
Content-Type: text/xml; charset="utf-8"
Connection: close
Content-Length: 2249
Server: 4.2.0-040200-generic DLNADOC/1.50 UPnP/1.0 ReadyDLNA/1.1.5
Content-Language: en
Date: Thu, 06 Oct 2016 19:25:56 GMT
...

And now minidlna starts responding to the www.grc.com Shields Up! uPnP port test 😞 -

[2016/10/06 20:26:44] minissdp.c:696: debug: SSDP M-SEARCH from 4.79.142.206:1900 ST: upnp:rootdevice, MX: 3, MAN: "ssdp:discover"
[2016/10/06 20:26:44] minissdp.c:257: debug: Sending M-SEARCH response to 4.79.142.206:1900 ST: upnp:rootdevice
[2016/10/06 20:26:44] minissdp.c:696: debug: SSDP M-SEARCH from 4.79.142.206:1900 ST: upnp:rootdevice, MX: 3, MAN: "ssdp:discover"
[2016/10/06 20:26:44] minissdp.c:257: debug: Sending M-SEARCH response to 4.79.142.206:1900 ST: upnp:rootdevice

Surely it should not even be responding to these!?!?!?  😞

Warm Regards
Julie
x

[w3wilkes]

Have you tested to see if this happens with the stock Netgear firmware? It might be that Richud just used their MiniDLNA server. If that's the case this device has been discontinued and I doubt we'll see any further updates to the Netgear firmware for this device. I'd also mention that there were plenty of completes about Netgear's media server not working all that well.

[jewelie]

@w3wilkes wrote:

Have you tested to see if this happens with the stock Netgear firmware? It might be that Richud just used their MiniDLNA server.

---

Turns out it does happen with the normal uPnP service too, so it's not just miniDLNA.  😞

[jewelie]

---

@w3wilkes wrote:

Have you tested to see if this happens with the stock Netgear firmware? It might be that Richud just used their MiniDLNA server. If that's the case this device has been discontinued and I doubt we'll see any further updates to the Netgear firmware for this device. I'd also mention that there were plenty of completes about Netgear's media server not working all that well.

---

miniDLNA seems to be being actively maintained and I gather that's an aspect thats updated in this firmware, but yeah as it happens on the normal uPnP service it's most likely present in the stock firmware too.  But yeah I think the way to address this might have to be a firewall rule worked into the config somehow (not quite sure how yet.)  Other than that, really liking this router (working out far better than the Archer VR900!)

[jewelie]

Well, I spent an evening trying to solve it but I'm stuck.  

Thought I'd be able to hook in an iptables command to the firmware that'd stop the UPNP SSDP packets coming in... but it looks me that the "udp" extension needs to be compiled in to filter udp packets by destination port.  😞

https://www.us-cert.gov/ncas/alerts/TA14-017A lists SSDP SEARCH packets (the ones that this firmware responds to if minidlna or upnp are unabled) as giving a x30 multiplication factor when used as a multiplying reflector for DDoS attacks, so no minidlna or upnp for me for the time being.  😞

Hopefully Rich will be able to come up with a solution when he's got time.  🙂

If not, perhaps I'll be able to reconfigure the device to just do DHCP, media sharing and minidlna and wireless and force a static route and gateway to the normal ISP router for the VDSL connection, or just give up and go back to the normal ISP router.  😕

[richud]

Hi,

I can't replicate this behvaiour.

There will be likely 3 upnp daemons listening on UDP port 1900 [ssdp],

bcmupnp = WFADevice
upnpd = DGND3700 (Gateway)
minidlnad = DGND miniDLNA Server

There are 11 port ranges (non protocol specific) that can be opened in the firewall to allow traffic from the external IP to the router itself.

(this router uses ACOS NAT , for firewall/NAT)

'fwlisten' will show these ports, the structure is like this;

520-520 means port 520 is open

520-519 means port 520 is shut

520-525 means port 520 to 525 would be open.

I have never seen 1900 be in that list.

The only way I can see that it would be open is if you disable NAT which disables the firewall entirely, or you are mapping that port manually or via upnp somehow to a device behind the router that is responding?

[jewelie]

Hi Rich

Thanks for having a look.

No, port 1900 never appears in fwlisten here either.

~ # fwlisten show
Current router firewall (non-NAT) open ports
============================================
Set 0 to 10
Disabled   = xxxx-(xxxx-1)
Open (One) = xxxx-xxxx
Open Range = xxxx-(xxxx+n)

--- listen port list ---
520-519, 8080-8079, 49152-49151, 500-499, 9091-9090, 5060-5059, 6000-5999, 2383-2383, 443-442, 21-20, 30001-30000, 

Advanced->Setup->NAT is set to "Enable" (both for WAN1 & WAN2 to cover all bases.)

Advanced->Setup->WAN Setup everything is unticked except WAN preference (Auto-Detect) and NAT filtering (secured.)

I've no port mappings, static routes, etc.  Or any consistent additional device in the background that could be doing this.

Please note the caveat that the router needs to have seen other devices on the network since either the uPnP port mapping service or DLNA has been enabled, which threw me at first (it didn't occur until other devices had made a connection to the router on the network - for instance our TV which searches for uPnP media devices - but the issue *continues* to then occur *after* these other devices are physically turned off and disconnected from the mains, so it cannot be the other devices on the network giving these responses.)

And the upnp test at grc.com still shows, for when just uPnP service is enabled-

HTTP/1.1 200 OK
ST: upnp:rootdevice
LOCATION: http://192.168.81.1:5000/Public_UPNP_gatedesc.xml
SERVER: Linux/2.6.12, UPnP/1.0, NETGEAR-UPNP/1.0
EXT:
CACHE-CONTROL: max-age=3600
USN: uuid:91735b26-5022-b67a-3ee8-531334f7d1b3::upnp:rootdevice

And when just the minidlna service is enabled-

HTTP/1.1 200 OK
CACHE-CONTROL: max-age=1690
DATE: Fri, 14 Oct 2016 16:21:21 GMT
ST: upnp:rootdevice
USN: uuid:4d696e69-444c-164e-9d41-2cb05d3a8841::upnp:rootdevice
EXT:
SERVER: 4.2.0-040200-generic DLNADOC/1.50 UPnP/1.0 ReadyDLNA/1.1.5
LOCATION: http://192.168.81.1:8200/rootDesc.xml
Content-Length: 0

Plus minidlna logs confirm both the source of the packet (the grc shields up service on 4.79.142.206) and the fact that it's the minidlna service that is responding-

[2016/10/14 17:20:04] minidlna.c:1030: warn: Starting ReadyDLNA version 1.1.5.
[2016/10/14 17:20:05] minidlna.c:1070: warn: HTTP listening on port 8200
[2016/10/14 17:20:05] getifaddr.c:338: info: Enabling interface 192.168.81.1/255
.255.255.0
[2016/10/14 17:21:21] minissdp.c:696: debug: SSDP M-SEARCH from 4.79.142.206:190
0 ST: upnp:rootdevice, MX: 3, MAN: "ssdp:discover"
[2016/10/14 17:21:21] minissdp.c:257: debug: Sending M-SEARCH response to 4.79.1
42.206:1900 ST: upnp:rootdevice

Throughout this port 1900 never appears in fwlisten and no other ports are detected as being open by grc.com.

I'm going to try to do some more specific tests to try to isolate what specific network activity it is that seems to turn this behaviour on if I can in order to make it easier to replicate.

Julie

x