Unoffical empeg BBS

Quick Links: Empeg FAQ | RioCar.Org | Hijack | BigDisk Builder | jEmplode | emphatic
Repairs: Repairs

Page 1 of 2 1 2 >
Topic Options
#261358 - 26/07/2005 08:01 Bugs in V3 A11
alex25
member

Registered: 30/06/1999
Posts: 179
Loc: Switzerland
I think we should start a new thread with alpha11 bugs. Peter, is there a chance we see a new alpha soon?

Let's start:
AF does not work for predefined stations (it does not search for AF at all), but works perfect if you search by the left / right buttons.

Selecting a frequency by remote control (search button) still crashes my player in two of three cases. (sigkill)

I had a reboot (sigkill) on my short 10 minute trip today (in tuner mode)

Top
#261359 - 26/07/2005 09:54 Re: Bugs in V3 A11 [Re: alex25]
alex25
member

Registered: 30/06/1999
Posts: 179
Loc: Switzerland
Here is the tracedump for the sigkill event (changing frequency by remote control). Just in case someone can do something useful with it:

player(79): user memory violation at pc=0x02002d08, lr=0x02002d0c (bad address=0x00000029, code 2)
pc : [<02002d08>] lr : [<02002d0c>]
sp : bd3ffcb0 ip : bd3ffcc0 fp : bd3ffcbc
r10: bd3ffcf8 r9 : bd3ffd08 r8 : bffffe38
r7 : bd3ffd0c r6 : 021e0a08 r5 : 021f43a8 r4 : 021f43a8
r3 : 00000001 r2 : 00000000 r1 : 00000001 r0 : 0225a6b0
Flags: nzCv IRQs on FIQs on Mode USER_32 Segment user
Control: D8E7517D Table: D8E7517D DAC: 00000015
Function entered at [<02002cf4>] from [<02052eac>]
Function entered at [<02052e68>] from [<0206d248>]
r5 = BD3FFCF0 r4 = 021E0A08
Function entered at [<0206d22c>] from [<0206d548>]
r4 = BD3FFD08
Function entered at [<0206d380>] from [<0206d2a4>]
r10 = 020DEA00 r9 = 021E0A08 r8 = 00004C14 r7 = 00000080
r6 = 00000014 r5 = BD3FFD4C r4 = 021E0A08
Function entered at [<0206d294>] from [<020dead4>]
Function entered at [<020dea9c>] from [<020dea8c>]
r5 = 021D40FC r4 = 021E0A08
Function entered at [<020dea00>] from [<0211c970>]
r5 = 021E0A20 r4 = BD3FFE40
Function entered at [<0211c8a8>] from [<0215334c>]
r4 = 00000000
Function entered at [<02151ac0>] from [<0211c6ec>]
r8 = 021E9224 r7 = 021E9210 r6 = 020DEA00 r5 = 00000005
r4 = 00000000
Function entered at [<0211c63c>] from [<0215334c>]
r5 = 00000000 r4 = 00000000
Function entered at [<00000074>] from [<021d1a28>]
Function entered at [<e39ffff4>] from [<eb000a3f>]
Function entered at [<2a00fef4>] from [<2a00ff00>]
Unable to handle kernel paging request at virtual address 2a00fef8
memmap = D8E74000, pgd = c3e74000
*pgd = 00000000, *pmd = 00000000
Internal error: Oops: 2
CPU: 0
pc : [<c00e3d90>] lr : [<c00198f0>]
sp : c2887f44 ip : c2887f00 fp : c2887f90
r10: 00000002 r9 : c3ecd0e0 r8 : 0000000c
r7 : 00000000 r6 : 2a00fef4 r5 : 2a00ff00 r4 : ea000030
r3 : 60000013 r2 : c0104284 r1 : 00000001 r0 : ea000020
Flags: nZCv IRQs on FIQs on Mode SVC_32 Segment user
Control: D8E7517D Table: D8E7517D DAC: 00000015
Process player (pid: 79, stackpage=c2887000)
Stack:
c2887f20: c00198f0 c00e3d90 60000013
c2887f40: ffffffff c3ecd0f8 c3ecc560 c2886000 c2887fb8 00000029 c0011b88 02002d0c
c2887f60: 00000029 00000002 c2887fb8 0000000f 00000029 00000000 00000002 bd3ffd08
c2887f80: bd3ffcf8 c2887fb4 c2887f94 c00120e4 c0011928 c010297c 021f43a8 021e0a08
c2887fa0: bd3ffd0c bffffe38 00000000 c2887fb8 c000a0c8 c001200c 0225a6b0 00000001
c2887fc0: 00000000 00000001 021f43a8 021f43a8 021e0a08 bd3ffd0c bffffe38 bd3ffd08
c2887fe0: bd3ffcf8 bd3ffcbc bd3ffcc0 bd3ffcb0 02002d0c 02002d08 20000010 ffffffff
Backtrace:
Function entered at [<c001191c>] from [<c00120e4>]
r10 = BD3FFCF8 r9 = BD3FFD08 r8 = 00000002 r7 = 00000000
r6 = 00000029 r5 = 0000000F r4 = C2887FB8
Function entered at [<c0012000>] from [<c000a0c8>]
r8 = BFFFFE38 r7 = BD3FFD0C r6 = 021E0A08 r5 = 021F43A8
r4 = C010297C
Code: ebfcd653 e2440010 (e5961004) e1a035a1 e59f20cc

Top
#261360 - 26/07/2005 10:26 Re: Bugs in V3 A11 [Re: alex25]
JBjorgen
carpal tunnel

Registered: 19/01/2002
Posts: 3584
Loc: Columbus, OH
After the upgrade, I've had trouble connecting to both players from emplode 2.10 via serial. I can connect fine through hyperterminal. Can anyone else verify this?
_________________________
~ John

Top
#261361 - 26/07/2005 12:12 Re: Bugs in V3 A11 [Re: alex25]
Daria
carpal tunnel

Registered: 24/01/2002
Posts: 3937
Loc: Providence, RI
I was able to wedge the player twice by fast-forwarding in a song too long last night. When I go out again in a bit I will try again over more songs.

Said song was encoded with lame, uniform bitrate.

Top
#261362 - 26/07/2005 12:57 Re: Bugs in V3 A11 [Re: Daria]
JBjorgen
carpal tunnel

Registered: 19/01/2002
Posts: 3584
Loc: Columbus, OH
RTFRN:

Quote:

* Known Issues

Long bursts of fast-forwarding or rewinding can cause a lockup.
_________________________
~ John

Top
#261363 - 27/07/2005 19:30 Re: Bugs in V3 A11 [Re: JBjorgen]
oliver
addict

Registered: 02/04/2002
Posts: 691
I'm now running A11 on my main unit, and I'm not positive if this audio glitch was in the previous alphas, but when toggling the pause mode on a mp3, I hear a faint pop in the audio playback. Can anyone else confirm this?

I've got crossfade on 0.5s, that's really the only 3.0 unique setting I've enabled.
_________________________
Oliver mk1 30gb: 129 | mk2a 30gb: 040104126

Top
#261364 - 28/07/2005 03:19 Re: Bugs in V3 A11 [Re: oliver]
alex25
member

Registered: 30/06/1999
Posts: 179
Loc: Switzerland
In Antwort auf:
I'm now running A11 on my main unit, and I'm not positive if this audio glitch was in the previous alphas, but when toggling the pause mode on a mp3, I hear a faint pop in the audio playback. Can anyone else confirm this?

Do you use the players equalizer? If yes, please try to set it to flat and try it again. I had similar problems with earlier alpha versions (the first one with the auto eq feature). That's why I don't use the equalizer anymore, but rather the bass and treble settings.

Top
#261365 - 31/07/2005 04:54 Re: Bugs in V3 A11 [Re: alex25]
Foz
member

Registered: 24/10/2000
Posts: 106
Loc: San Jose, CA
The long down press in the playlist menu functionality seems to be borked in A11 (the "go back to last playlist menu" option).

The normal behavior is that when I'm at the playlists menu, a long downpress brings me to the last place I originally was browsing in the playlist (the last album, artist or song I select. From there, you can then select a new song/artist/album/whatever and then go into the enqueue/append/replace menu.

The behavior now skips the last playlist entirely and drags me straight to the enqueue menu, and in fact auto selects enqueue, resulting in a duplicated playlist. Looks like the intermediate keypresses are just "assumed"

-- Gary F.
_________________________
Eeyore, Original Owner -- Mk II 80 Gb, Blue S/N #090000803 Tigger, 2nd Owner -- Mk IIa, 80 Gb, Blue S/N #40103789

Top
#261366 - 31/07/2005 09:11 Re: Bugs in V3 A11 [Re: Foz]
Shonky
pooh-bah

Registered: 12/01/2002
Posts: 2009
Loc: Brisbane, Australia
Quote:
The long down press in the playlist menu functionality seems to be borked in A11 (the "go back to last playlist menu" option).

The normal behavior is that when I'm at the playlists menu, a long downpress brings me to the last place I originally was browsing in the playlist (the last album, artist or song I select. From there, you can then select a new song/artist/album/whatever and then go into the enqueue/append/replace menu.

The behavior now skips the last playlist entirely and drags me straight to the enqueue menu, and in fact auto selects enqueue, resulting in a duplicated playlist. Looks like the intermediate keypresses are just "assumed"


This happened in one of the early betas also but wasn't there in v3a8 I don't think. The only workaround I've found is to only hold the button long enough to record a long keypress.

On my empeg it seems to happen when the drives need to be spun up. If they are already spinning the problem doesn't happen (or not as much at least).
_________________________
Christian
#40104192 120Gb (no longer in my E36 M3, won't fit the E46 M3)

Top
#261367 - 02/08/2005 07:15 Re: Bugs in V3 A11 [Re: Shonky]
iopcool25
new poster

Registered: 09/06/2004
Posts: 43
Loc: New York
how come i can use my emplode. It gives me a database error when trying to sync database of mkII.

Top
#261368 - 30/08/2005 17:12 Re: Bugs in V3 A11 [Re: iopcool25]
oliver
addict

Registered: 02/04/2002
Posts: 691
I was just on my way into work, and I was listening to Del Tha Funkee Homosapien (Both Sides Of The Brain), and track 14 (Catch all This) came to an end and all I heard was some really nasty noise. I looked at the Seek Tool, and noticed it was about 5 seconds past the end of the track and still playing. So I skipped ahead, and the next track started to play. So I rewound back to the end of the previous track and it did the same thing again.

So I just skipped ahead to track 15 again, and was listening to that. However, at the end of that track the player completely froze (except hijack, did the reboot machine, I did check the Vital Signs before rebooting, and the player was at about 3.5, 3, 2 for the load averages) and played that track again. Same thing at the end of track 15 (Phoney Phranchise).

After I get home to my empeg power brick. I'll grab those songs off my empeg. What programs should I use to analyze these tracks? Or should I just upload them so the empeg guys can download them?


Edited by oliver (30/08/2005 17:14)
_________________________
Oliver mk1 30gb: 129 | mk2a 30gb: 040104126

Top
#261369 - 30/08/2005 17:16 Re: Bugs in V3 A11 [Re: alex25]
oliver
addict

Registered: 02/04/2002
Posts: 691
Quote:
Quote:
I'm now running A11 on my main unit, and I'm not positive if this audio glitch was in the previous alphas, but when toggling the pause mode on a mp3, I hear a faint pop in the audio playback. Can anyone else confirm this?

Do you use the players equalizer? If yes, please try to set it to flat and try it again. I had similar problems with earlier alpha versions (the first one with the auto eq feature). That's why I don't use the equalizer anymore, but rather the bass and treble settings.


Also, Sorry for the late reply. However, all the answers to those questions are No, my EQ is very flat, I've never used the autoeq, and the VolAdj feature is always disabled. Also the Tone settings in Hijack are set to Off.
_________________________
Oliver mk1 30gb: 129 | mk2a 30gb: 040104126

Top
#261370 - 01/09/2005 08:15 Re: Bugs in V3 A11 [Re: alex25]
russell
journeyman

Registered: 22/05/2004
Posts: 50
I've noticed a couple of problems since switching to v3a11.

1. When listening to the Tuner in the car the audio muting (for car phone etc) dosn;t work. It works perfectly when in player mode. I've note yet tried the tuner with any other versions of the software so can't really say if this is a bug specific to v3a11 or more of a "feature"

2. Some times the player randomly moves on to the next track part way through the current one. Going back to the skipped track normally results in it playing to completion
_________________________
Mk2a 64mb 60gb

Top
#261371 - 01/09/2005 10:47 Re: Bugs in V3 A11 [Re: russell]
wfaulk
carpal tunnel

Registered: 25/12/2000
Posts: 16706
Loc: Raleigh, NC US
ISTR that there's a setting for what mute does while in Tuner mode. Maybe that got reset? Or I could just be making stuff up.
_________________________
Bitt Faulk

Top
#261372 - 01/09/2005 11:33 Re: Bugs in V3 A11 [Re: russell]
Roger
carpal tunnel

Registered: 18/01/2000
Posts: 5683
Loc: London, UK
Quote:
2. Some times the player randomly moves on to the next track part way through the current one.


I've never seen that in any of the v3 alphas. What type of tracks (MP3, FLAC, etc.)? Does the length of the track displayed on screen agree with the length of the track as reported by another player (e.g. Windows Media Player)? What did you use to encode them? Are they constant or variable bitrate? What bitrate? Mono/stereo? Does it seem to be the same tracks all the time, or is it everything on the player?
_________________________
-- roger

Top
#261373 - 02/09/2005 05:54 Re: Bugs in V3 A11 [Re: alex25]
frog51
pooh-bah

Registered: 09/08/2000
Posts: 2091
Loc: Edinburgh, Scotland
Had an interesting bug I have not managed to pin down yet - doesn't appear to be connected to a particular track or playlist, and isn't repeatable deliberately, but sometimes when the end of the track is reached, something seems to hang.

Functionality appears perfect, except nothing plays - the song remains at the end, and the timestamp is the last second of the song. If it is at the end of a 3 minute 25 song, and I skip forward or back, it goes to 3:25 in the next song and does nothing. I have not yet managed to get a log as it has never done it when I have it hooked up at home (although in the dock it does think it is in the car)

Only solution is reboot through hijack which works every time.
_________________________
Rory
MkIIa, blue lit buttons, memory upgrade, 1Tb in Subaru Forester STi
MkII, 240Gb in Mark Lord dock
MkII, 80Gb SSD in dock

Top
#261374 - 15/09/2005 22:17 Re: Bugs in V3 A11 [Re: alex25]
Waterman981
old hand

Registered: 14/02/2002
Posts: 804
Loc: Salt Lake City, UT
First time I have seen this bug(for A11), so I figured I better mention it. Yesterday I had the infamous source switching happen. First time with A11, which I've been running since it was released. It happened the same as when the bug was in previous alphas. Revoving, and reinserting the player fixed it.
_________________________
-Michael

#040103696 on a shelf
Mk2a - 90 GB - Red - Illuminated buttons

Top
#261375 - 01/10/2005 15:13 Re: Bugs in V3 A11 [Re: alex25]
Roger
carpal tunnel

Registered: 18/01/2000
Posts: 5683
Loc: London, UK
Long down press on 'Playlists' (to take you to the last selected playlist) seems to go too far (and select 'Replace') on my empeg with 3a11. Anyone else confirm this?
_________________________
-- roger

Top
#261376 - 02/10/2005 03:12 Re: Bugs in V3 A11 [Re: Roger]
Shonky
pooh-bah

Registered: 12/01/2002
Posts: 2009
Loc: Brisbane, Australia
Yup. Although mine seems to Append rather than Replace. This isn't new in v3a11 though. I think it has existed in all the v3 alphas.

It doesn't always do it though. Sometimes it works OK. It seems to work better if the drives are already spun up.
_________________________
Christian
#40104192 120Gb (no longer in my E36 M3, won't fit the E46 M3)

Top
#261377 - 19/10/2005 13:29 Bookamrks are not saved while player is caching music [Re: alex25]
elperepat
enthusiast

Registered: 11/01/2002
Posts: 211
Loc: Qc, Canada
When the player is caching (small dark hdd icon in upper right), if I try to set a bookmark, it is not saved properly. When I try to go to that bookmark, I come up with an empty playlist. If I wait for the hdd icon to dissapear and then save the bookmark, it works every time.
_________________________
Patrick

Top
#261378 - 19/10/2005 13:35 Re: Bugs in V3 A11: sigkill error [Re: alex25]
elperepat
enthusiast

Registered: 11/01/2002
Posts: 211
Loc: Qc, Canada
Changing volume while empeg is caching for the first time after startup often produces a sigkill.

3.0a11 mk2a 32M 2x30G Hijack v440
_________________________
Patrick

Top
#261379 - 17/08/2006 18:48 Re: Bugs in V3 A11 [Re: alex25]
Will
new poster

Registered: 06/05/2001
Posts: 12
Loc: Plymouth, UK
I've been running a11for a couple of months I guess. Today it all went wrong. All was well when I went to work. On coming home the unit just kept rebooting. It would boot to showing the track playing (but not actually, and duration not changing, buttons unresponsive) and after a variable amount of time reboot. This it continued to do until pulled from the sled. The unit was very hot at this point. This behavior contued even fter the unit had been reinserted when cold. Same thing when plugged into the mains. V2 final now installed and all is well.

Top
#261380 - 21/01/2007 15:21 Re: Bugs in V3 A11 [Re: Will]
Nobbie
journeyman

Registered: 12/02/2002
Posts: 59
Loc: Herts, UK
Running A11, has the same as the last poster, no big problem, just re-booted and fine.

Randomly the software hung at the end a track, manual reboot(read as taking out of sled live, and re-inserting), unit went through the boot sequence, then instantly hung on the track again. Manual reboots, and from within hijack do nothing. Had to bring it indoors and as soon as it booted up Pause it, then re-boot, then hold to standby, then pic another play list on resume. Unit was playing a 20 song mp3 playlist on shuffle.
_________________________
Getting Old.

Top
#309135 - 15/04/2008 13:51 Re: Bugs in V3 A11 [Re: alex25]
peter
carpal tunnel

Registered: 13/07/2000
Posts: 4179
Loc: Cambridge, England
Originally Posted By: RFC2131 section 4.1
The 'xid' field is used by the client to match incoming DHCP messages with pending requests. A DHCP client MUST choose 'xid's in such a way as to minimize the chance of using an 'xid' identical to one used by another client. For example, a client may choose a different, random initial 'xid' each time the client is rebooted

Unfortunately there is a bug in 3.00 alpha 11, Receiver Edition only, such that it doesn't do this -- it doesn't adequately randomise the xid on boot, so two Receiver Edition car-players on the same network both get the same xid, and thus any attempt by the DHCP server to assign an IP address to either one of them, is actioned by both, so both get the same IP address. Which is bad.

There are some workarounds:
  • Give static IP addresses to Receiver Edition car-players. Note that you can't switch a car-player from DHCP to static while Receiver Edition is on it; you need to temporarily reinstate the Standard Edition.
  • Partition the network somehow, so that broadcast packets don't reach both players; this is likely to need features that domestic switches don't have.
  • Whenever you're powering-on a Receiver Edition car-player, temporarily unplug the others from the network.
  • Using the serial port, Ctrl-C and restart the player on all the units (or, technically, all but one). When the player restarts, it will pick a new random xid and thenceforth[1] be capable of obtaining a unique address.

This bug was probably my fault, sorry frown

Peter

[1] Tanstaafl is right, using a word that the BBS hasn't seen before is harder than you'd think.

Top
#309137 - 15/04/2008 13:54 Re: Bugs in V3 A11 [Re: peter]
tfabris
carpal tunnel

Registered: 20/12/1999
Posts: 31592
Loc: Seattle, WA
Quote:
Note that you can't switch a car-player from DHCP to static while Receiver Edition is on it;


Even by editing config.ini directly?
_________________________
Tony Fabris

Top
#309138 - 15/04/2008 13:56 Re: Bugs in V3 A11 [Re: peter]
tfabris
carpal tunnel

Registered: 20/12/1999
Posts: 31592
Loc: Seattle, WA
Also: What impact would this have on a network that contains both Rio/Dell Recievers, *and* one or more car players running Receiver Edition?
_________________________
Tony Fabris

Top
#309139 - 15/04/2008 14:03 Re: Bugs in V3 A11 [Re: tfabris]
peter
carpal tunnel

Registered: 13/07/2000
Posts: 4179
Loc: Cambridge, England
Quote:
Even by editing config.ini directly?

That would work fine. I just meant that the "normal" car-player method of changing it, using Emplode, doesn't apply.

Quote:
Also: What impact would this have on a network that contains both Rio/Dell Recievers, *and* one or more car players running Receiver Edition?

Receiver Edition only interferes with other Receiver Editions, not with real Receivers of either variety. And multiple real Receivers all DHCP'ing on the same network is extremely well-(at)tested.

Peter

Top
#309146 - 15/04/2008 15:02 Re: Bugs in V3 A11 [Re: peter]
tfabris
carpal tunnel

Registered: 20/12/1999
Posts: 31592
Loc: Seattle, WA
Thanks for those clarifications. :-)
_________________________
Tony Fabris

Top
#309147 - 15/04/2008 15:34 Re: Bugs in V3 A11 [Re: peter]
mlord
carpal tunnel

Registered: 29/08/2000
Posts: 14489
Loc: Canada
Originally Posted By: peter
Unfortunately there is a bug in 3.00 alpha 11, Receiver Edition only, such that it doesn't do this -- it doesn't adequately randomise the xid on boot, so two Receiver Edition car-players on the same network both get the same xid, and thus any attempt by the DHCP server to assign an IP address to either one of them, is actioned by both, so both get the same IP address. Which is bad.

Can this be patched (one or two bytes) in the binary ?


Edited by mlord (15/04/2008 15:34)

Top
#309157 - 15/04/2008 17:41 Re: Bugs in V3 A11 [Re: mlord]
peter
carpal tunnel

Registered: 13/07/2000
Posts: 4179
Loc: Cambridge, England
Originally Posted By: mlord
Can this be patched (one or two bytes) in the binary?

I can't foresee so, no. Some extra code would need adding, there's no patch-one-instruction fix I can think of. And of course I don't have access to the source any more (it's not even clear who does -- probably Freescale), so even if I could figure out somewhere to logically patch, it'd be hard to convert that idea into an actual patch. For now (and there aren't AFAICT all that many users of Receiver Edition) it'll have to be the workarounds.

Peter

Top
#309160 - 15/04/2008 19:39 Re: Bugs in V3 A11 [Re: peter]
mlord
carpal tunnel

Registered: 29/08/2000
Posts: 14489
Loc: Canada
Originally Posted By: peter
For now (and there aren't AFAICT all that many users of Receiver Edition) it'll have to be the workarounds.


Okay, thanks. If the userbase ever becomes significant (more than 2?), then perhaps we could just have Hijack modify the DHCP packets as they pass through.

Cheers

Top
#312819 - 09/08/2008 10:11 Re: Bugs in V3 A11 [Re: mlord]
mlord
carpal tunnel

Registered: 29/08/2000
Posts: 14489
Loc: Canada
Originally Posted By: mlord
Originally Posted By: peter
For now (and there aren't AFAICT all that many users of Receiver Edition) it'll have to be the workarounds.


Okay, thanks. If the userbase ever becomes significant (more than 2?), then perhaps we could just have Hijack modify the DHCP packets as they pass through.

Cheers

This bug is also present in the regular car2-v3alpha11 load as well, so now I *really* want to squash it.

I suppose I'll have to have Hijack replace the CID on outgoing DHCP packets -- and probably put the old CID back again on incoming ones that match, right ?

Top
#312824 - 09/08/2008 13:22 DHCP trace from car2-v3alpha11 [Re: mlord]
mlord
carpal tunnel

Registered: 29/08/2000
Posts: 14489
Loc: Canada
Here's the wireshark trace. First, a short summary for those with good eyesight, and then an attached binary blob that can be reloaded back into wireshark for viewing/interpretation.

A more readable copy of the image below is available here.


Attachments
wireshark.png

Description: Screen capture

v3a11_dhcp_trace.bin (614 downloads)
Description: tcpdump format output from wireshark.




Edited by mlord (09/08/2008 13:26)

Top
#312825 - 09/08/2008 13:35 Re: DHCP trace from car2-v3alpha11 [Re: mlord]
mlord
carpal tunnel

Registered: 29/08/2000
Posts: 14489
Loc: Canada
One problem seems to be that the empeg's bootp request has the "broadcast bootp flag" set, so the server must use broadcast when replying.. and that reply then gets picked up by all other empegs on the subnet.

Most of the other DHCP clients here do not set that bit, so the server sends a targeted response to them.

I could try having Hijack clear that bit on the outgoing packet, and see if the empeg copes with it.

-ml


Edited by mlord (09/08/2008 13:37)

Top
#312826 - 09/08/2008 13:43 Re: DHCP trace from car2-v3alpha11 [Re: mlord]
mlord
carpal tunnel

Registered: 29/08/2000
Posts: 14489
Loc: Canada
Mmm.. I suppose that trace is not quite complete -- used a switch during the capture. It still illustrates the problem (two players claim the same IP address, even though they were assigned different IP addresses by DHCP), but not the complete sequence.

So for completeness, I'll later hook up a shared hub and run Wireshark from there to get all of the packets.

Cheers

Top
#312827 - 09/08/2008 13:58 Re: DHCP trace from car2-v3alpha11 [Re: mlord]
peter
carpal tunnel

Registered: 13/07/2000
Posts: 4179
Loc: Cambridge, England
Originally Posted By: mlord
One problem seems to be that the empeg's bootp request has the "broadcast bootp flag" set, so the server must use broadcast when replying.. and that reply then gets picked up by all other empegs on the subnet.

Most of the other DHCP clients here do not set that bit, so the server sends a targeted response to them.

I could try having Hijack clear that bit on the outgoing packet, and see if the empeg copes with it.

Hmmm... I do remember now that we set that bit for a reason -- we found a situation (perhaps it was a particular server) where it didn't work without the "broadcast replies" bit set. Still, that was the last remaining bit of the puzzle. You'll notice that your captured packets 3 and 8 (OFFER replies from the server aimed at the two clients) have the same xid in (Wireshark: "Transaction ID"), but different chaddr (Wireshark: "Client MAC address"). The Empeg, utterly incorrectly, matches on the former but not the latter.

So I suspect that checking incoming UDP to port 68 (bootpc) and dropping on the floor (or scrambling the xid of) packets whose chaddr isn't ours, would fix the problem.

Peter


Edited by peter (09/08/2008 14:05)
Edit Reason: chaddr, obviously, not ciaddr

Top
#312830 - 09/08/2008 19:25 Re: DHCP trace from car2-v3alpha11 (Hijack v501) [Re: peter]
mlord
carpal tunnel

Registered: 29/08/2000
Posts: 14489
Loc: Canada
Originally Posted By: peter
So I suspect that checking incoming UDP to port 68 (bootpc) and dropping on the floor (or scrambling the xid of) packets whose chaddr isn't ours, would fix the problem.


Yes, that certainly does seem to fix things.
Hijack v501 is now released, with this workaround incorporated.

Thanks, Peter!

Top
#312831 - 09/08/2008 19:29 Re: DHCP trace from car2-v3alpha11 (Hijack v501) [Re: mlord]
mlord
carpal tunnel

Registered: 29/08/2000
Posts: 14489
Loc: Canada
Of course, I have hardcoded the packet offset for the client MAC address -- to match where my own DHCP server puts the data.

But I have no idea if it is *always* at that exact offset, or whether more intelligent parsing of the packet is necessary to ensure it works everywhere (?).

EDIT: A consequence of which, is that DHCP might not work for anyone but me. smile

Cheers

Top
#312832 - 09/08/2008 20:14 Re: DHCP trace from car2-v3alpha11 (Hijack v502) [Re: mlord]
mlord
carpal tunnel

Registered: 29/08/2000
Posts: 14489
Loc: Canada
Originally Posted By: mlord
But I have no idea if it is *always* at that exact offset, or whether more intelligent parsing of the packet is necessary to ensure it works everywhere (?).

According to RFCs 951 & 2131, the offset is constant, so no worries.

But just in case someone wants to run a DHCP *server* on the empeg, it might be slightly safer to also check the bootp message type field as well.. as is now done in Hijack v502.

Cheers


Edited by mlord (10/08/2008 11:17)

Top
Page 1 of 2 1 2 >