NBX phone boot protocol

NBX phone boot protocol

This page is here since there is a total lack of online support from 3com.

The 3com phones use a protocol that runs at the ether layer.

u_char pkt[] =
    {           // this packet is 802.2 encapsulation
	// dest ether
	// src ehter
	// packet len // 0x0410 or 0x0012
	// optional vlan or qos data may be here
    0xaa, 0xaa, 0x03,  // DSAP SSAP
    0x00, 0xe0, 0xbb,   // org code (same as mac header)
    0x44, 0x4c, // protocol type
    0x00,       // 0 orig message, 0x80 ack
    0x01,       // message type
    0x00, 0x1a, // size
    0x00, 0xe0, 0xbb, 0x04, 0x27, 0xc5,         // my address

    0x02,       // hardware 2=nbset
		// 3=TLIM, 4=DSSBLF, 5=Elvis, 0,6,7,..=nothing
    0x03,       // rev nbset_03

    0x18, 0x13, 0x55, 0xa1,     // phone serial no
    0x02, 0x00, 0x05, 0x00,
    0xc4, 0x01,                 // current flash ver? r401
    0x00, 0x00,
    0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
    0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
	// 02Nov01

};
The message type can be 
2: broadcast
1: phone request download
3: ncp acking #2
4: data packet
5: eof
The order is:
type 2 brodcast from ncp (every ten seconds)
phone sends request of type 1
ncp sends a non broadcast packet type 3
phone sends ack type 3.  An ack will set ack byte to 0x80, swaps src/dest ether
  addresses and returns packet.
ncp sends type 4 data packets
phone sets ack type 4.  An ack will set ack byte to 0x80, swaps src/dest ether
  addresses and returns packet. 
ncp sends type 5 data packet
phone boots code it just downloaded and doesnt seem to ack 05 packets
If the phone sends the wrong flash version, then the ncp sends a program that seems to be the flash rewriter. The phone rewrites its flash and then reboots asking for the current version.

If the phone send the correct flash, then the normal phone program is run and the phone starts its normal initialzation procedure that uses a completely different protocol. This means that the downloader can be indpendant of the nbx.

The phones use a simple 16 bit checksum to make sure the download file is in tact. The checksum of most of the files needs to be 0x600d. The last 8 files of the phone's downloads seems to be 0x600d,csum,0x0000,0x0000. It would appear that the program that writes the checksum writes the expected value followed by the needed 16 bit number.

Sample code is called 105.35:downclient.c



Back to Tim's Homepage Back to current subject Related Links thogard@abnormal.com
 This page was last updated Tuesday, 30-Jul-2002 05:24:22 UTC Copyright 2000-2018 thogard™ is a trademark of Tim Hogard