Whirlpool

Hiya,

I found an updated version of the WebExcel firmware on-line at Pete Ashton's Weblog (a very good user help site for the WebExcel modems).

The version info is:

Firmware Version: ETHADSL_USB_080902_REL9P
Customer Software Version: 080902_REL9P

It seems to fix a problem with the IP address settings returned via the built-in DHCP server in half-bridge mode. I no-longer have to muck about with two IP addresses on my NIC to get the modem working on FreeBSD.

I have noticed stability problems with the old REL9K firmware, where the PPP connection in half-bridge mode would time out (disconnect) even though I set a timeout of 0 seconds (disabled). Hopefully this will fix the problem. There's no point running server processes if the modem goes off-line after a while of no activity... :(

The VPN passthrough continues to work with REL9P as it did with REL9K.

I upgraded my PT-3808 WebExcel from REL9K to REL9P via the web interface without any problems. I first updated it with the firmware.dlf file, then the bootrom.dlf. The update is supposedly applicable to the PT-3812 also. Your milage may vary... ultimately flash your modem at your own risk!

Enjoy,
John.

The above URL isn't the latest firmware after all. There is a slightly newer version available from the MicroNet website (see the firmware for the product SP3351).

The version of this newer firmware is:

Firmware Version: ETHADSL_USB_080902_REL9P
Customer Software Version: 080902_REL9P2

The REL9P firmware was fairly unstable for me in half-bridge mode. The PPP connection kept dropping out. I'll report back if there are similar problems with REL9P2. If there is, I guess there's no choice but to downgrade to REL9K which seemed to work OK, but wasn't perfect (idle connections would drop after a few hours).

Again, I had no trouble flashing my PT-3808 WebExcel with this firmware. There are also flashing instructions on-line, provided by MicroNet.

John.

I just updated my PT-3812 to REL9P2 without any problems. Was hoping it may make "Virtual Servers" accept a range of ports. IT DOES NOT. However it does upgrade the SHOWTIME software and all seems to be working very well.

A word of caution to anyone considering a firmware flash. Read the Pete Ashton's Website and read it in detail, esspecially anthing written by a user called Bazza. Alot of people in England have killed this equipment by stupidly flashing it with the wrong firmware.

Have Fun,
Dave.

Dave writes...

Have Fun,

Think I might leave mine as it is . It works faultlessly . :)

Hi Dave,

When you flashed your PT-3812, did you use the SP3351_9P2.zip that others have mentioned as being appropriate for the PT-3808 and possibly the PT-3812, or did you get the SP3354_9P2.zip file which is listed a few entries lower down in the listing on the micronet site. It might be useful to emphasise that there are two different downloads available for the single port and four port versions of this modem respectively.

It is interesting to note that there is a common firmware upgrade instructions file (SP3354_FrmUpg.zip) which applies for both downloads.

I've recently set up two Swiftel ADSL services using the Webexcel PT-3812 and both are working fine with zero installation hassles. I got the modems at $90 each. You certainly can't argue with the price. I'm now about to have a go at upgrading the firmware and was keen to know exactly which upgrade file you used.

Cheers,
Gary.

blerton writes...

When you flashed your PT-3812, did you use the SP3351_9P2.zip that others have mentioned as being appropriate for the PT-3808 and possibly the PT-3812, or did you get the SP3354_9P2.zip file which is listed a few entries lower down in the listing on the micronet site. It might be useful to emphasise that there are two different downloads available for the single port and four port versions of this modem respectively.

Download the two zip files and compare them -- they're exactly the same, byte-for-byte! i.e. it doesn't matter which you choose.

Do you want to upgrade the firmware to fix any particular problem? My advice is to leave it alone unless you have a specific need. e.g. to "fix" issues with half-bridge mode on an OS like FreeBSD.

John.

John,

Thanks for that. Thanks also for the reference to Pete Ashton's weblog. I've read through most of it. It should be mandatory reading for anyone about to fiddle with a firmware upgrade on this modem.

Why do I want to "dice with death"? I've noticed a number of people (like yourself) in various forums, commenting on whether or not particular problems might be fixed with a firmware upgrade. As an aside, you documented your 2 stage upgrade to REL9P and then to REL9P2. You mentioned that REL9P gave you stability problems in half-bridge mode. Did REL9P2 finally fix this issue for you? I fully subscribe to "If it ain't broke, don't fix it" so I probably won't touch it until I need to. At the moment everything is just fine with just two windoze boxes sharing the connection.

However, my next step is to expand the LAN side of things somewhat. My "about to be replaced" LAN consisted of a number of unix and windoze boxes sharing an ISDN link. The server was an old SUN workstation and I've also got a couple of PCs running FreeBSD. The new LAN will have a FreeBSD server, at least one unix (Linux or FreeBSD) workstation and a number of windoze boxes. It will be implemented gradually as I work out how to do what I need to do. I've used FreeBSD right from the early days when I migrated to it from 386BSD so I wont have a problem with installation and basic configuration of FreeBSD. What I need to learn is how to properly secure it all and to optimise the server for best LAN performance. I also will want to play with remote administration, etc.

At this stage, I've chosen the PT-3812 because it's cheap and may very well be able to do what I want in the short term. I figure that by the time I need something better, the higher quality units will be a lot cheaper anyway.

I would like to thank you for your original post in this thread. The information provided was very helpful.

Cheers,
Gary.

blerton writes...

You mentioned that REL9P gave you stability problems in half-bridge mode. Did REL9P2 finally fix this issue for you?

Yes and no. There remains two problems that occur on the WebExcel modem in half-bridge mode.

1. In order for the modem to have any Ethernet IP connectivity, a DHCP request must be sent to the modem. This isn't normally a problem, but combined with the second one below, it is. I'm with Swiftel and have a static IP address. There's no real need to require a DHCP client request to "enable" the modem...

2. The DHCP lease time is set to about 60 seconds on the ethernet LAN interface. This normally isn't a problem on some OSs, like WinXP, however under FreeBSD (and Linux) what happens is that when the lease is renewed (with the exact same parameters; as I have a static IP address), the IP address settings for the ethernet interface are updated (to the same thing). In practice I've observed that this update causes packet loss and high latency. Since it occurs frequently, it is a problem.

You might think that this is a problem with FreeBSD rather than the modem. However I don't understand why the firmware authors didn't just use the DHCP lease time on the half-bridge PPP connection as the same lease time on the internal LAN DHCP. That way the client doesn't have to constantly renew. If it happened once every few days, I wouldn't mind a short burst of packet loss... but this is too frequent to go unnoticed.

My quick and dirty solution to this problem was to add a hook script to my DHCP client (/etc/dhclient-enter-hooks) to kill the DHCP client after the first renew so that (a) the DSL modem gets its initial DHCP request to "turn on" and (b) my machine gets the correct IP address settings without having to statically configure them, yet doesn't endure the nasty per-60 second disruption. The problem with this is that if there is loss of power to the modem (or something equally as weird), then it will "turn off" while expecting a new DHCP client request before it "turns on" again... and of course, a message such as that will never be sent.

A better solution to the above might be to fudge the script so that it doesn't update any of the ethernet interface parameters if those params are the same. That way the DHCP renews can keep occurring every 60 seconds without any packet loss/latency issues as the actual ethernet interface params aren't touched.

The best solution, is of course, for the firmware authors to fix their DHCP lease times to match that of the ISP PPP connection. I believe the Billion also has this problem. A sign of immaturity in DSL modem manufacturers?

I originally purchased the WebExcel because of the Conexant chipset allowing me to use it in USB mode on my X-Box while still using the Ethernet interface for my internal LAN (running Linux, of course). Since I probably won't be having an X-Box gateway anytime soon (my FreeBSD machine is much better; with heaps of RAM and disc), I should have got a decent Ethernet modem instead... there were no reports of problems such as this on any forums or websites that I visited before I came across them myself. Just bad luck I suppose...

BTW- if you're wanting to use a single Linux/FreeBSD box as a gateway to your LAN, there's no need for the 4 port WebExcel; the single port PT-3808 in half-bridge mode is all you need. Do all your firewall/NAT/uPnP/etc on your gateway. You'll have much better control over everything (with better logs). The tradeoff is time and your level of experience in setting it up.

Don't get me wrong, so far the WebExcel PT-3808 is a great hardware product... but the firmware stinks. I guess the hardware side was taken care of by Conexant; the rest of the hardware in the box is just glue to support the all-in-one ASIC to do its job. *sigh*

John.

Hi guys,

The problem with half bridge mode that I had was accessing the modem's config while the WAN link was up.

Obviously as soon as the WAN link is up the modem will re-assign a new IP address to the client computer. After this happens the LAN IP address of the modem (default of 10.0.0.2) becomes inaccessible.

Is this because the modem and the computer are no longer on the same subnet, or is it just a firmware bug?

My solution to this problem was just to physically disconnect the phone line to the modem... WAN link goes down, DHCP server re-assigns a LAN IP address to client computer, modem config becomes accessible again. Half the time I actually had to force a renew of the DHCP lease on the client computer in order to regain access to the modem. I'm not sure if this was a modem firmware bug, an MS Windows glitch, or a misconfiguration of DHCP server lease times. WHat ever it was it became a bit of a hassle, because of this I don't run in half-bridge mode anymore.

Does the REL9P2 firmware address the above problems?

...on another subject, have any of you guys tried running the REL9P2 firmware in NAT router mode and full bridged mode at the same time?

I know some firmware versions do support this configuration. It can be very handy to have internet access via the modems NAT and be able to establish an additional PPPOE link without any modem configuration changes or reboots. Obviously your isp needs to support multiple logins for this to work.

tuuw writes...

Is this because the modem and the computer are no longer on the same subnet, or is it just a firmware bug?

To give you a bit of background to my post first... I had been with OptusNet for many years and had set up a headless box on one end of our house. The Optus coax went to a wall socket next to the box, along with an Ethernet port that went under the house via cat5 to my room at the rear.

When I first got DSL, I was unable to connect this headless box because I had no phone line access in that room. Before I routed the cabling to that room, I had used my WebExcel and Swiftel connection with my WinXP box in my room...

When I was using half-bridge mode under WinXP, I simply set up HTTP access to the modem on the WAN side, and restricted the IP address to my Swiftel static IP address. Thus when my WinXP box had that IP address, I could access the configuration without problems (in effect, the HTTP connection was on the WAN side).

Since getting my FreeBSD gateway back up, I can do it an additional way. I simply give my ethernet interface that is connected to the DSL modem two IP addresses. One is obtained via DHCP and is the half-bridge Swiftel public IP address; the other is an internal IP address on the same subnet as the DSL modem. In my case, the DSL modem has the IP address 172.16.0.1. My FreeBSD PC has the IP address alias 172.16.0.2.

On my internal LAN DNS server, I've got an entry named dsl-modem that resolves to 172.16.0.1 so I can simply type into my browser: http://dsl-modem:PORT/ and I get access to the web interface. (Note: I need to change the port of the HTTP configuration mini-server from 80 to some other PORT because otherwise Apache won't be able to run on my gateway and be accessible on the public network.)

My FreeBSD gateway knows to route packets destined for 172.16/16 to the right Ethernet interface where the DSL modem lies because of its netmask.

An alternative is to set up a static route that pushes out packets destined for 172.16 out the Ethernet interface connected to the modem and it should also work. This might be possible under WinXP via the route command in a command prompt.

...on another subject, have any of you guys tried running the REL9P2 firmware in NAT router mode and full bridged mode at the same time?

I never had a need; but does it make sense to do this? In this "mode" do clients have statically assigned IP addresses? If they use DHCP, surely they'd get the half-bridge mode IP address?

It can be very handy to have internet access via the modems NAT and be able to establish an additional PPPOE link without any modem configuration changes or reboots. Obviously your isp needs to support multiple logins for this to work.

If the PC connected via ethernet to the modem establishes a PPPoE link, then the modem is operating in full-bridge mode; not half-bridge... I'm not sure what you're getting at here...?

As you hint at, I was under the impression that each ISP could only support one PPP connection to each user, per IP address. i.e. if you're given one IP address from your ISP, only one PPP connection to them can have it. If a modem is in NAT mode, it is running PPPo{A,E}, so how can there be yet another PPP connection running elsewhere unless your ISP has given you a block of IP addresses? I don't imagine any ISP to allow simultaneous PPP logins unless they've allocated to you more than one address.

John.

hmm... ok.. has anyone anyone been able to use the Virtual Server Port Forwarding with the new firmware?

e.g. Setup Web-Server,
Setup Gaming Server

I've been in contact wiht Bazza from Pete Ashton's site, and i will be writing a thorough FAQ on this modem soon... thus... i need to get some info first.

Hi,

Just wondering hows the progess with the FAQ.
There seems to be another modem the amx-64e, which is similar to the webexcel. The modem itself looks different but i think that the chipset is the same (conexant), correct me if im wrong.

I was just wondering if there is a fix for that stupid bug (port 6667 & 6668 for mirc), and whether we can make this webexcel pt3812t modem do range port forwarding.
Has anyone tried to upgrade their webexcel pt3812t with the amx-64e firmware at
www.amigo.com.tw/download.htm#amxca64e ?

Just curious and frustrated.

Thx all.

G'Day,
I've got a PT-3912T and so far, it's been running reasonably well. However, I'm running a Linux based server/gateway/coffee machine (ie does everything), and I tried running the modem in half-bridge. But it would drop the connection (WAN link still active, but nothing else happeneing) after a random time interval. This bugged me, so I put it back into the normal mode and tried to turn on port forwarding. I can tell it forward any port I want, I can save and reboot the modem however many times I want and it won't forward 1 single, solitary packet. Ditto with the DMZ setting.

Has a) anybody else experienced this? and b) if so, and you've upgraded the firmware, has this fixed it?

Hi
Best way is to fix the half-bridge lease problem for which I have given an extensive set of instructions. It is particularly bad with linux or freebsd or so I have read.
forum-replies.cfm?t=2047...2922920#r2922920
Firmware upgrade will not fix the half-bridge. Don't know about packet forwarding. I did attempt one firmware upgrade and ended up having to pull the modem apart and usb flash it back.