|
to HiVolt
Re: [DSL] Cellpipe 7130 questions1.0.4.3EF-ISAM |
|
HiVolt Premium Member join:2000-12-28 Toronto, ON |
HiVolt
Premium Member
2014-Aug-9 8:24 pm
Ah, that one is a bit older, they did hide the stats it in that version if memory serves correctly... |
|
TP-Link Archer C7 Technicolor DCM476 Grandstream HT701
|
Is there a way to get the newer firmware? Got stats from Teksavvy.
GLine Profile: V26944-20032_11328-2048_00011 DLM State: DISABLED | Equip. Type: 7330_REM Sync Rate: d26926.0/u11327.0 kbps RCO: d53.0/u52.0% Noise Margin: d19.5/u14.7 dB Power: d13.8/u5.2 dB Attenuation: d16.3/u21.2 dB (Approx. Distance: 1.18~2.08km) Block Count: d2165403281.0/u271581380.0 |
|
RizzleQCunningham's Law Enthusiast Premium Member join:2006-01-12 Windsor, ON Ubiquiti UDM-Pro Ubiquiti U6-LR
|
RizzleQ
Premium Member
2014-Aug-9 10:13 pm
(Those are phenomenal stats, BTW ) The way to get updated firmwares on modems was by configuring it in Routed mode (enter your username and password in the modem; not the router) and leaving it like that overnight. I don't know if Bell is pushing the latest firmware on this modem anymore, but at least try that and see how it goes. |
|
|
Thanks, I'll give it a try. |
|
Teddy Boomk kudos Received Premium Member join:2007-01-29 Toronto, ON |
So regarding firmware upgrades on these things.. I have one unit with 1.0.4.4R8. Was able to unlock telnet using these instructions: » Re: [DSL] Is Cellpipe not the perfect bridge/dumb modem? Telnet?However, I have another unit with 1.0.4.3EF-STINGER, and the telnet unlock instructions do not work on it. The /util_cfgstore.html page 404s. (page missing from older firmware confirmed here) » Re: [DSL] Is Cellpipe not the perfect bridge/dumb modem? Telnet?Meanwhile, this post contains what I believe to be a full flash dump including the latest and best firmware version, 1.0.4.4R8-wh (or just 1.0.4.4R8 ?). » Re: CELLPIPE= 100% reliable full 50/10 on any remote, one caveatI believe the concatenation of block2 + block 3, or of block 4 + block 5 should be the firmware. I'll try with the serial console on my 1.0.4.3 unit sometime soonish, but any thoughts on this would be appreciated. |
|
TP-Link Archer C7 Technicolor DCM476 Grandstream HT701
|
to redblack
This modem seems quite stable on 25/10 in passthrough mode using an Asus router. I'm not getting full upload but quite close so it doesn't really matter. |
|
HiVolt Premium Member join:2000-12-28 Toronto, ON |
HiVolt
Premium Member
2014-Aug-11 8:43 am
said by Mike2009:This modem seems quite stable on 25/10 in passthrough mode using an Asus router. I'm not getting full upload but quite close so it doesn't really matter.
Well your stats look great so something else is limiting your upload. I remember I had no problem with the Cellpipe getting 10meg up. Anyway, you're on a 7330 remote so if it croaks for any reason you can replace it with other modems for fairly cheap. |
|
TP-Link Archer C7 Technicolor DCM476 Grandstream HT701
|
said by HiVolt:said by Mike2009:This modem seems quite stable on 25/10 in passthrough mode using an Asus router. I'm not getting full upload but quite close so it doesn't really matter.
Well your stats look great so something else is limiting your upload. I remember I had no problem with the Cellpipe getting 10meg up. Anyway, you're on a 7330 remote so if it croaks for any reason you can replace it with other modems for fairly cheap. I already have a Sagemcom and Huawei so no shortage of modems here. |
|
HiVolt Premium Member join:2000-12-28 Toronto, ON |
HiVolt
Premium Member
2014-Aug-11 9:21 am
You're in good shape then. You should try the Huawei and see if the upload improves. |
|
|
I always get full upload on the Huawei and Sagemcom.
Speakeasy speed test shows full upload with the Cellpipe.
Download Speed: 24666 kbps (3083.3 KB/sec transfer rate) Upload Speed: 10012 kbps (1251.5 KB/sec transfer rate) |
|
Mike2009 |
It's just the speed tests. Teksavvy and Nexicom are giving less than full upload while others show full upload. Nothing to worry about. |
|
reiyu join:2014-01-08 North York, ON |
reiyu
Member
2014-Aug-11 1:46 pm
the speedtest isn't perfect due to flash and java. the worst languages to code something with.
and yes, you have nothing to worry about unless you're missing more than a full megabit of speed constantly. |
|
Teddy Boomk kudos Received Premium Member join:2007-01-29 Toronto, ON 1 edit |
to Mike2009
Have you seen the firmware upgrade yet? I've finally hooked up to the console port. I can confirm this stuff: » exploring the alcatel lucent cellpipe 7130Locked console, but interupting boot gets you bootloader options that are interesting. Presumably I can network boot a copy of 1.0.4.4R8 ripped from the full flash dump. Once booted into 1.0.4.4R8, if I'm lucky, the firmware is flashable through the web interface. Upshot being, manually upgrading these should be possible. Still looking for comments though |
|
|
I haven't had a chance to set it up in routed modem to see if the firmware upgrades. I'll do that next weekend. |
|
|
to Teddy Boom
I switched to Dry Loop and that meant I sent the Cellpipe back and now have a Sagemcom so can't help on this effort, but it looks good so far! |
|
HiVolt Premium Member join:2000-12-28 Toronto, ON |
to Teddy Boom
Teddy, only the latest R8 firmware has the web firmware upload section. the previous didn't have it.
Would be good if you could somehow figure out how to make it a full bridge with an internally tagged VLAN 35. that was my issue, i couldn't get my router to tag the VLAN 35 and therefore it wouldn't authenticate. |
|
Teddy Boomk kudos Received Premium Member join:2007-01-29 Toronto, ON |
said by HiVolt:Teddy, only the latest R8 firmware has the web firmware upload section. the previous didn't have it. Yes for sure, but.. What I'm hoping is that I can do a network boot of the latest firmware, and then it will be running the latest firmware and that will allow the flash. Alternatively, it looks like the bootloader can write to flash at low level, block by block. For the VLAN and bridge mode thing.. I don't know.. I've read that other thread, and I'm not so sure progress is possible on that front. If the firmware is upgradeable, all Cellpipes become a viable option. |
|
lleader join:2011-01-01 Mississauga, ON |
Teddy, you might want to note my comment back in August of last year. » Got old CellPipe not in use? Newer firmware out there. |
|
Teddy Boomk kudos Received Premium Member join:2007-01-29 Toronto, ON 4 edits |
Very interesting lleader, thanks! I'm having trouble doing a tftpboot from the bootloader.. the tftpboot command initially complains that serverip is not set. If I setenv serverip I can get tftpboot to run. The file transfer starts but stalls. I'm using SolarWinds TFTP server. I might try tftp32--seems the block size might be an issue? Do I have to set the firmware length environment variable to match the firmware I'm trying to boot from maybe? Or a million other bootloader options/variables? There is also a bootp command, anybody have pointers for using bootp? I guess there has to be a bootp server responding to make that work? tftp32 is supposed to support bootp, but I don't see any options about that. I'm able to enable console in the 1.0.4.3EF-STINGER unit by simply changing the environment variable in the bootloader: setenv console_enable 1
saveenv
There is a bootloader environment variable called firmware_upgrade.. I changed it to 1, but I've got no idea what it does :) (maybe it searches for a tftp file to be pushed at it? I could read the messages more thoroughly I suppose..) Changing the boot partition from 2 to 1 (and saving) has loaded 1.0.4.2-STINGER, so it definitely works, which is nice :) EDIT: Oh, maybe I'm interpreting the bootloader help file incorrectly: » rechtzeit.wordpress.com/ ··· -u-boot/Hmmmm :D EDIT AGAIN: Well, I have tftp transfers completing successfully now (address in tftpboot is a memory address, not an IP address :uhh: ), but I still can't get it to boot from the file that is transfered.. |
|
|
With uboot the file needs to get transferred to a specific address in memory and then you need to boot an address. Depending on the image type the two addresses may be different, and also the address that you need to boot may be different from image to image.
If you dump out the uboot environment with "printenv" then you may get some clues on how it normally boots the files that are on the flash partition. |
|
Teddy Boomk kudos Received Premium Member join:2007-01-29 Toronto, ON |
Thanks notfred, I was coming around to that, but I'm still not sure I get it.. There might be only one address in RAM that the image can be loaded to, and then possibly a different address, 10 bytes higher maybe, that should be booted from? I've been loading the image to 80400000 (because of environment variable settings, see below), and then trying to bootm from that same location. The modem just boots from whichever flash image it is set to, even though there is an image in memory it was told to boot from. So, the location could be wrong. I'm wondering if some environment variables could be overriding my instruction and booting from flash anyway? Here is a dumb of the environment variables from a previous thread. It is pretty close to mine, except for a few adjustments I've discussed in the last two posts: > printenv
��:eauthor=Leo@analog devices
bootdelay=1
baudrate=57600
preboot=echo;echo Type "h" for HELP. Have fun!;echo
netboot=dhcp;tftp;run netargs; bootm
nfsargs=setenv bootargs root=/dev/nfs ip=dhcp
localargs=setenv bootargs root=/dev/mtdblock2 ip=dhcp
addmisc=setenv bootargs $(bootargs) console=ttyS0,$(baudrate) read-only=readonly
netargs=run nfsargs addmisc
flash_nfs=run nfsargs addmisc;bootm $(kernel_addr)
flash_local=run localargs addmisc;bootm $(kernel_addr)
netboot_initrd=dhcp;tftp;tftp 80600000 initrd;setenv bootargs root=/dev/ram ramdisk_size=8192 ip=dhcp;run addmisc;bootm 80400000 80600000
rootpath=/export/miniroot-mipsel
autoload=no
myfs_start=0xbfd40000
kernel_addr=BFC60000
ramdisk_addr=B0100000
u-boot=u-boot.bin
bootfile=kernel.img
load=dhcp;tftp 80400000 $(u-boot)
load_kernel=dhcp;tftp 80400000 $(bootfile)
ethaddr=00:00:00:01:02:05
bootcmd=bootm 0xbf060000
bootargs=myfs_start=0xbf1a0000 rootfstype=cramfs root=/dev/mtdblock3
boot_partition=2
firmware_upgrade=0
boot_successfully=1
fw_length=1048576
fw_crc=ffffffff
console_enable=0
u-boot-ver=1.1.4b
ipaddr=192.168.1.2
upgrade_uboot=tftp $(u-boot);protect off all;erase bf000000 bf05ffff;cp.b 0x80400000 bf000000 60000
initenv=protect off all;erase bf020000 bf03ffff
stdin=serial
stdout=serial
stderr=serial
ethact=voxEmac
Environment size: 1293/131068 bytes
|
|
|
So it looks like it is using a kernel that gets loaded in to 80400000 and an initrd that gets loaded in to 80600000 and using bootm to boot it. It's passing various args about what is the root partition, either an NFS, Flash or Ramdisk one and also passing the console and a read-only parameter. The trick is that bootcmd is the command executed by default, and then you have to work back through all the variable substitutions to get what the command line actually is. There's a pretty good uboot command reference in section 5.9 of » www.denx.de/wiki/DULG/Manual |
|
Teddy Boomk kudos Received Premium Member join:2007-01-29 Toronto, ON |
to redblack
So I thought it might be worth figuring out the memory map, but I don't get it :) The boot messages: » Re: exploring the alcatel lucent cellpipe 7130The flash memory map is pumped out in there (16Mbytes total): 0x00000000-0x00060000 : "ADI uBOOT Partition"
0x00060000-0x001a0000 : "ADI Flash OS Partition"
0x001a0000-0x00800000 : "ADI Flash FS Partition"
0x00800000-0x00940000 : "ADI Flash OS-2 Partition"
0x00940000-0x00f60000 : "ADI Flash FS-2 Partition"
0x00f60000-0x01000000 : "ADI Config JFFS2 Partition"
RAM is 32Mbytes, aka 0x02000000, which the boot messages also reference: Determined physical RAM map:
memory: 02000000 @ 00000000 (usable)
But then we get this: Initial ramdisk at: 0x80000000 (0 bytes) and this: ## Booting image at bf800000 ... and this: Load Address: 80010000 Entry Point: 802af000 WTF? Wouldn't RAM normally be the first 32Mbytes and flash the next 16Mbytes and so you have addresses from 0x00000000 to 0x02FFFFFF. They keep talking about addresses way outside that space. So, I'm missing something important about this syntax.. |
|
|
to redblack
a bit off topic but do these still have the horrible 42mbps limit? I remember in an older thread guspaz mentioned it but I can't remember if that was just in ppoe bridge mode |
|
RizzleQCunningham's Law Enthusiast Premium Member join:2006-01-12 Windsor, ON Ubiquiti UDM-Pro Ubiquiti U6-LR
|
RizzleQ
Premium Member
2014-Aug-14 5:30 pm
said by eeeaddict:a bit off topic but do these still have the horrible 42mbps limit? I remember in an older thread guspaz mentioned it but I can't remember if that was just in ppoe bridge mode They do and only in bridge mode. |
|
|
does the real (tftp hacked) bridge mode fix this problem? |
|
Teddy Boomk kudos Received Premium Member join:2007-01-29 Toronto, ON |
to RizzleQ
said by RizzleQ:said by eeeaddict:a bit off topic but do these still have the horrible 42mbps limit? I remember in an older thread guspaz mentioned it but I can't remember if that was just in ppoe bridge mode They do and only in bridge mode. I've just been playing with this a little. Older -STINGER firmware (possibly 1.0.4.2R?-STINGER) actually gets full speed in PPPoE pass through. 1.0.4.4R8, which reports suggest is a better firmware in general, only gets to 43mbps in PPPoE pass through. |
|